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FOREWORD 


“Technology  for  Manpower,  Personnel,  Training,  and  Safety  (MPTS  )  Tradeoff 
Decisions”  requests  the  development  of  computer-based  technology  to  integrate  Ml'  l  'S  und 
human  factors  (HF).  This  integration  is  to  occur  under  the  Logistics  Support  Analysts 
Record  umbrella,  with  emphasis  on  exploiting  computer-aided  design  (CAD)  and  matt 
modeling  technology.  The  proposed  effort  responds  most  directly  to  the  manpower, 
personnel,  and  training  (MPT)  and  CAD  portions  of  this  requit^-ntent.  seeking  further 
integration  through  the  reliability  (R&M)  engineering  design  interface  rather  than  the  111' 
and  safety  design  interface. 

The  central  tenet  of  this  effort  is  that  the  most  direct  integration  of  .VlP'l'  into  sy  steiu 
design  is  through  R&M  engineering.  The  R&M  interface  is  the  primary'  deiemtinant  of  the 
nature  and  volume  of  the  workload  that  the  maintenance  force  will  experience.  HF  and 
safety  interfaces  deal  with  issues  such  as  package  size,  displays,  connectors,  etc.,  which 
help  determine  how  long  a  given  task  will  take,  but  do  not  influence  its  frequency  or 
nature.  HF  inputs  generally  come  in  the  form,  of  static  design  guidelines  and  are  not 
interactive  with  any  part  of  the  system  e.xcept  physical  layout.  Decisions  about  consiiiueiu 
equipment  are  generally  made  with  reference  to  mission  requirements  and  to  R&M 
estimates.  These  R&M  parameters  are  only  obliquely  related  to  the  manpower  required  to 
service  the  emerging  system  and  are  not  interactive  with  them. 

The  approach  to  increasing  the  integration  between  R&M  and  manpower  developed 
features  a  proactive  manpower/R&M  translation  tool  to  suppon  system  design  tradeoffs 
among  reliability,  maintainability,  and  the  profile  of  AFSs  required  to  support  design 
changes.  This  previously  demonstrated  approach  will  also  feature  a  training  and  personnel 
quality  requirement  estimation,  based  upon  the  baseline  compari.son  system.  This  portion 
of  the  proposed  system  is,  essentially,  an  integration  of  the  logistic  support  analysis  and 
instructional  system  development  processes. 

This  Phase  1  effort  identifies  the  major  functional  requirements  for  an  integrated 
MPT/R&M  analysis  tool,  proposes  an  approach  to  meet  these  requirements,  and  assesses 
the  fea‘’ibi[ity  and  risks  of  a  Pha.se  II  project  to  develop  and  demonstrate  such  a  system. 
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PREFACE 


This  effort  wa:;  perfomied  for  the  Armstrong  Laboratory,  Logisue:>  Rescarcfi 
Division,  Acquisition  Logistics  Branch,  under  the  terms  of  Contract  Number  F4 1624-9! 
C-5()01.  Research  was  perfomed  by  the  Dayton  regional  office  of  Systems  Lxploration. 
Inc.  The  principal  investigator  was  .Nir.  Terr>'  M.  Miller 

Johnny  Jernigan  and  Theodore  Meyers,  both  fonnerly  of  Systems  Exploration. 
Inc.,  provided  helpful  inputs.  Thanks  also  to  Dr.  Btu’ry  Deer  of  Neirologic  and  .Major 
Greg  Clark,  Major  Bill  Weaver,  and  Mr.  Dick  Cronk  of  the  Air  Force  for  help  witli 
manpower  estimating  models. 
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1.  INTRODUCTION 


1  The  Small  Business  Innovative  Research  Phase  I  results  presented  in  this  report  comprise 

i  an  overv'iew  and  analysis  of  current  design  practices  covering  Manpower,  Personnel,  and  Trainmu 

(VIPT)  issues;  detailed  descriptions  of  an  approach  to  overcome  some  of  die  current  imfx'diments 
to  MPT  integration;  a  proposed  workstation-based  architecture  to  implement  some  of  these  idea' ; 
I  and  a  proposed  development  program  leading  to  a  demonstration  of  an  MP T/sysiem  design  trade 

j  off  workstation. 

^  The  rationale  underlying  this  particular  MPT  integration  approach  is: 

I  1 )  Our  goal  is  to  increase  the  responsiveness  of  design  to  MPT  centered  logistics  issues. 

2)  The  design  interfaces  for  logistics  are  through  human  factors  (Ml-),  which  is  often  groujted 
with  Safety,  and  through  Reliability  and  Maintainability  (R&M)  engineering.  HP  provides  design 
input  to  the  system  mainly  as  design  requirements  and  standards,  compliance  with  which  is 
determined  at  several  points  during  the  design  process,  R&M  parameters  are  performance 
estimates  derived  from  the  system  functional  and  physical  design  characteristics.  R&.M  estimates 
tor  an  emerging  design  are  compared  against  R&M  targets  set  at  the  beginning  of  the  effon. 

3)  Manpower,  not  reliability,  not  maintainability,  drives  MPT  logistic  costs.  Other  hmstic  is.sues 
(e.g.,  sparing,  support  equipment)  are  driven  by  R&M  parameters.  The  relationship  hcivsccn 
R&M  and  Manpow'er  estimates  is  a  tortuous  complex.  Because  of  this  problem.  R&.M  goals  arc 
used  as  management  controls  for  the  MPT  logistic  profile  of  a  sysiem.  Trade-offs  among  MP  T 
and  R&M  are  unavailable  to  the  design  team.  As  a  consequence’,  designers  .satisfice  .MP  f  issues 
instead  of  optimizing  them. 

4)  Quantitative  Personnel  and  Training  calculations  are  dependent  upon  Manpower  estimates;  i.e.. 
one  needs  to  know  how  many  of  a  panictilar  Air  Force  Specialty  (AFS)  will  be  required  before  one 
can  calculate  the  training  and  recruiting  burden  associated  with  an  emerging  system. 

5)  The  most  direct  route  to  increasing  the  responsiveness  of  design  to  .MPT  is  to  subsume 
Manpower  under  R&M,  providing  Manpower-by-AFS  estimates  in  addition  to  R&M  when 
evaluating  the  status  of  a  design  effort. 

Results  of  individual  analysis  topics  undertaken  as  part  of  the  Phase  1  effon  luo  c  been 
integrated  into  the  general  framework  of  this  report,  which  was  es.sentially  built  around  two  of  the 
Phase  I  survey  and  analysis  tasks  (Task  1,  Define  tentative  integrated  system  architecture  and 
major  functions;  and  task  4,  Relationship  between  logistics  issues  and  manpow'er-by-AFS  t. 
Issues  under  Phase  I,  Task  3  (Task  analysis  as  simulation  script)  and  Task  8  (Feasibility  of 
automated  training  and  technical  order  generation)  were  deemed,  respectively,  too  irrelevant  and 
too  ambitious  for  incorporation  in  the  Phase  II  demonstration  workstation  development  effort. 
Relevant  findings  from  these  and  the  other  topical  surveys  and  analyses  have  been  integrated  into 
the  general  scheme  of  this  report. 

n.  ANALYSIS  OF  CURRENT  MANPOWER,  PERSONNEL  AND  TRAINING  DESIGN 

PRACTICE. 

Statement  of  the  Problem 

The  Manpower,  Personnel,  and  Training  (MPT)  profile  for  a  currently  fielded  system  or 
fleet  may  not  be  optimal  when  applied  to  an  emerging  weapon  system.  Adjustments  to  the 
predecessor  system  MPT  profile  or  to  the  emerging  system  can  produce  a  better  match  between  the 
field  support  setup  and  the  emerging  system,  producing  a  more  supportable  sysiem.  Limiting 
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these  beneficia!  adjusiments  is  a  design  analysis  process  that  does  not  evaluate  liic  KcVM  prohle  <>! 
the  enterging  system  directly  against  maintenance  slots  within  a  maintenance  environment,  but 
rather  against  R&M  design  goals  set  early  in  the  acquisition  process  betore  much  t't  the  design 
work  is  undertaken.  This  exigency  is  due  to  the  lack  of  analytical  approaches  and  tools  tor  tins 
evaluation.  The  focus  of  the  proposed  effort  is  to  develop  and  validate  an  integrated  iogisiics 
analysts  system  to  evaluate  the  MP'l'  profile  and  Reliability  and  .Maintainability  (R&.M) 
characteristics  of  a  new  system.  To  describe  the  approach,  the  management  and  technic  ;' 
requirements  of  the  design  process  must  first  be  explained. 

The  Design  of  l^arge  Systems 

In  the  past,  aircraft  were  designed  by  individuals.  One  person  could  do  e\er\thing 
leqiiired:  select  and  engine;  design  a  fuselage,  add  wings;  empennage,  and  lantiing  gear;  [lerlorm 
stress  analysis;  and  start  cutting  metal;  However,  advances  in  aircraft  maieriaH,  aerod>  namic^. 
and  electronics  resulted  in  the  modern  design  team,  numbering  in  the  thousands,  to  develop  a 
modern  military  aircraft.  Some  overall  strategy  to  coordinate  the  efforts  ot  these  engineers  was 
clearly  needed.  The  military,  after  its  experience  with  large  system  design  problems  during  Work! 
War  II  and  the  post-w'ar  era,  developed  tlie  systems  engineering  concept  in  the  I'A'iO’s  to  manage 
the  development  of  new  weapon  sy.stems.  The  basic  notions  of  extended  attention  to  retiuiremen!-' 
and  close  regulation  of  design  data  development  have  proven  largely  successful  but  increasingly 
expensive  over  the  past  40  years. 


Systems  Engineering 

Engineering  is  the  act  of  devising  and  .teleeting  among  alternative  approaches  to  accomplish 
some  fixed  purpose.  It  is  little  different  with  large  engineering  projects,  such  as  developing  a  new 
aircraft,  except  that  a  great  deal  of  additional  attention  needs  to  be  paid  to  management, 
communication,  and  documentation.  The  fundamental  concept  of  systems  engineering  is  to 
repeatedly  divide  the  design  problem  into  increasingly  smaller  pieces,  desigft  the  smaller  pieces, 
then  assemble  them  into  the  complete  design.  The  systems  engineering  process  occurs  according 
to  the  following  five  phases: 

Develop  Functional  Description 

The  system  functionality  is  detemiined  by  developing  candidate  strategies  to  fulfill  .some  set 
of  mission  requirements.  For  example,  an  Air  Force  requirement  may  be  to  attack  an  air  base  1(X) 
km  behind  the  enemy's  forward  position.  Tw'o  candidate  functional  descriptions  may  he  for  (a)  an 
aircraft  capable  of  carry'ing  a  sufficient  payload  at  high  speed  without  being  detected  by  radar  or  (b) 
an  unmanned  cruise  missile.  Competing  candidate  functional  descriptions  are  evaluated  and  a  final 
functional  concept  for  a  weapon  system  is  selected  and  fully  developed.  The  functional  de.scripiion 
contains  system  performance  parameters  that  serve  as  goals  or  constraints  for  system  performance; 
MPT  issues  are  usually  presented  as  manpower  slots  per  aircraft,  support  environment  constraints, 
and  R&.M  system  goals.  It  is  this  system  description,  with  .some  description  of  technological 
solutions  to  critical  design  points,  that  provides  the  basis  for  the  Milestone  0  decision. 

Assign  Functional  Allocation 

The  weapon  system  functionality  is  apportioned  into  subsystem  capabilities.  For  example, 
the  functional  requirements  of  systen:  payload,  range,  and  speed  are  broken  dow  n  into  engine 
thrust,  gross  airframe  weight,  weapon  system  delivery  capacity,  landing  gear  load  reqv;’''''mems, 
fuel  system  requirements,  and  so  on.  This  functional  aliocaiion  process  is  performed  down  to  a 
level  where  either  existing  components  to  suit  the  function  can  be  identified  or  the  component  th..t 
needs  to  be  developed  can  be  specified  in  terms  of  its  technology,  size,  risk,  cost,  logistics  burden, 
and  so  on.  The  resultant  detailed,  decomposed  system  functional  description  is  intended  to  iiivc 
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management  a  clear  notion  of  how  the  final  product  will  behave.  Allocaied  is.sues  in  art 

restricted  to  R&M  parameters;  manpower  slots  per  aircraft  are  normally  not  allocated  down  to 
particular  constituent  systems.  The  result  of  this  process  -  the  allocated  system  functional  baseline 
--  is  the  subject  of  the  Preliminary  Design  Review  (PDR)  early  in  the  dcmonsiration/validation 
acquisition  phase. 

Design  and  Integrate  Subsystems 

The  system  functional  descriptions  are  translated  into  hardware  designs,  e.g.,  an  oleo  strut 
is  identified  or  designed  to  absorb  the  projected  landing  geas  loads.  .MPT  issues  are  still  of  the 
R&M  variety,  with  system  considerations  now  calculable  from  the  predicted  R&M  characterisucs 
and  support  environment  considerations.  The  design  baseline  system  is  reviewed  at  the  Critical 
Design  Rev  iew  (CDR)  prior  to  fabrication.  The  subsystems  are  fabricated  and  the  s\'stem  is 
assembled. 

Evaluate  System  Pertonnance 


The  ability  of  the  system  to  pertbmi  its  required  function  is  tested.  MPT  is  computed  usi.ig 
measured  R&M  characteristics  and  field  maintenance  concepts  data. 

Reconsider  System  Specification 

The  functional  requirements  are  continually  review^ed  throughout  the  weapon  ss  stem  s 
development  process  and  field  life  because  of  changes  to  the  mission  requirements,  the  threat,  and 
available  technology.  This  ongoing,  continual  review  proce.ss  occasionally  leads  to  the  cancellation 
of  an  effort  or  a  significant  redefinition  of  the  mission.  For  example,  the  B1  started  life  in  the 
196l)s  as  a  high  altitude  strategic  bomber.  Its  design  was  later  adapted  to  a  low  level  mission 
because  of  improved  Soviet  defense  prior  to  its  entering  a  production  program.  This  led  to  rcdttceu 
capabilities  and  reliability. 

Systems  engineering  is  continually  being  improves.  Concurrent  Engineering  t'CE)  has 
recently  emerged  as  a  catch-all  phrase  for  the  automated  management  of  system  infomiation  during 
the  design  process.  CE  is  intended  to  provide  a  flexible  means  of  accommodating  changes  and 
updates  to  functional  requirements  and  de.sign  parameters  w'hich  have  sy.stem-wide  impact.  The 
motivation  for  CE  is  to  provide  the  contractor  the  means  to  manage  their  design  data  and  i(.spo!H! 
to  government  data  reporting  requirements  without  delay  to  the  designers  in  their  primarc'  work. 

Logistics 

Logistics  is  the  branch  of  military  .science  dealing  with  planning,  implementing,  and 
managing  personnel,  materiel,  facilities,  and  related  issues.  Modern  logistics  relies  heavily  upon 
mathematical  models  and  analysis  of  historical  data  to  predict  and  allocate  resources  supporting 
emerging  and  fielded  systems.  This  activity,  termed  logistics  analysis,  is  u.sed  extensively  to 
predict  resource  requirements  during  .system  development,  which  is  our  resent  concern. 

Logistics  analysis  has  two  purposes.  The  first  is  to  propose  and  evaluate  specific  design 
choices  affecting  the  logistics  requirements  of  the  emerging  systeni.  This  is  the  earliest  purpose  of 
logistics  analysis  and  often  consists  simply  of  ranking  design  alternatives  on  a  logistics  erterion 
such  as  manpower,  transportability,  or  other  measure  appropriate  to  the  choices  at  '  ..u.  The 
subsequent  purpo.se  of  logistics  analysis  is  detailed  planning  for  logistics  support  of  the  emerging 
system. 
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Figure  1,  from  AF'LC  Pamphlet  8(X)-17,  illustrates  these  two  purposes  of  logistics  analysis 
against  the  phases  of  the  acquisition  process.  The  .significant  changes  in  the  system  design  arc  in 
the  levels  of  design  detail  that  exist  at  subsequent  phases  of  the  process.  A  corresponding  incTcasc 
in  the  level  of  detail  and  certainty  of  logistics  support  requirements  also  occurs  as  the  design 
matures.  During  the  pre-concept  pha.se,  in  theory  if  not  in  practice,  the  logistician  providc,> 
information  about  previous  logistics  experience  with  systems  similar  to  ones  that  might  [irovidc 
solutions  to  the  effort’s  capability  requirement.  Later,  the  logistician  provides  feedback  alxait 
subsystems  based  both  upon  previous  experience  with  similar  systems  and  anah  scs  of  the 
emerging  design.  Finally,  the  design  having  been  finalized,  the  logistician  analyzes  the  emerging 
design  exclusively  (the  R&M  parameters  of  which  are  still  based  upon  experience  with  previous 
systems,  through  reliability  and  maintenance  task  time  analyses)  and  turns  the  use  of  his  analyses 
exclusively  to  the  planning  function.  The  important  thing  to  note  is  that  the  logistician  needs 
flexible  analyses.  They  must  be  responsive  to  the  broad  range  of  alternatives  generated  and 
evaluated  early  in  the  development  cycle,  while  they  must  provide  accuracy  alxive  all  cisc  later  in 
the  program. 


SYSTEM 
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Figure  1 

Role  of  Lx)gistic.s  in  the  Acquisition  Process. 
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Aircraft  supportability  is  determined  by  a  complex  interaction  of  equipment  reliability, 
maintenance  requirements,  AFS  and  maintenance  organization  structures,  training  requirements, 
and  the  personnel  system.  Consideration  of  these  issues  is  currently  the  responsibility  of 
numerous  logistics  specialties.  Interaction  among  these  specialties  is  accomplished  sequentially,  as 
some  of  the  specialties  depend  upon  the  output  of  the  analyses  of  others  for  input  to  their  particular 
analysis.  The  entire  process  is  repeated  a  number  of  times--at  least  once  per  phase  ot'  the 
acquisition  cycle  --  with  the  feedback  from  previous  iterations  and  more  fundamental  analyses 
within  the  same  cycle  providing  input  for  each  analysis  activity. 

Figure  2  portrays  the  data  dependencies  within  a  single  cycle  of  the  design  process.  'I'he 
heavily  shaded  boxes  represent  the  specialties  that  are  active  in  the  earliest  phases:  Design  revievss, 
task  analysis,  technical  order  development,  and  instructional  system  development  tasks  are  active 
only  in  the  final  stages  of  system  de-'clopment. 


Figure  2 

Logistics  Specialties  Data  Dependencies. 


Operational  RcquiremeiU-s.  The  fundamentui  source  ol’  system  design  [taramctcrs  and 
concomitant  support  requirements  is  operational  analysis.  Meeting  the  mission  requirements  is  the 
primary  concern  of  a  weapon  system  development  program.  In  addition  to  primary  design 
characteristics  such  as  payload,  speed,  range,  etc.,  much  of  the  logistics  support  requirement  is 
generated  by  the  general  concept  chosen  to  fulfill  the  mission  requirement.  The  operational 
requirements  immediately  set  reliability  constraints  for  systems  deemed  critical  to  successful 
sorties  Additional  »-eliability  constraints,  and  maintenance  time  constraints  as  well,  are  detennined 
by  the  operational  requirements  in  that  the  time  available  to  maintenance  between  sorties  i.> 
constrained  by  sortie  rate  and  duration  requirements.  The  process  of  detennining  both  the  physical  i 

layout  and  the  .sortie  requirements  is  a  pliant  process  involving  interaction  among  the  user,  the 
acquiring  organization,  and  contractors  in  determining  w'hether  advances  in  the  state  of  the  art.  . 

shifts  in  the  perceived  threat,  and  political  conditions  are  amenable  to  proposing  a  new  start.  ^ 

Often,  these  forces  will  produce  logistics  goals  such  as  direct  maintenance  slots  per  aircraft  or 
maintenance  concept;  these  logistics  goals  are  not  always  justified  by  hard  analyses. 

Engineering.  SE  and  the  equipment  design  specialties  (e.g.,  avionics,  propulsion,  flight 
controls,  etc.)  develop  and  manage  the  system  design  and  perfV'rmance  parameters  during  sy-tem 
development.  In  the  past,  logistics  performance  specifications  and  expectations  were  aggregated 
via  systems  engineering  along  with  the  system’s  performance  parameters.  These  functions  are 
now  delegated  to  the  logistics  community  in  Air  Force  acquisitions,  allegedly  because  logistics 
issues  were  shortchanged  by  the  engineering  community.  The  recent  emergence  of  CE,  w  ith  its 
concern  for  centralized  coordination  of  a  development  effort  and,  particularly,  its  concern  for  data 
exchange  standards,  is  an  attempt  to  reintegrate  the  equipment  and  logistics  areas  under  a  common 
management  umbrella 

R&M  Engineering.  Also  called  Supportability  Engineering,  R&M  engineering  is  the 
specialty  within  the  individual  engineering  disciplines  that  deals  with  predicting  failure  rates  and 
with  maintenance  planning  to  repair  or  avert  these  failures.  R&M  engineering  provides  a  useful 
qualitative  distinction  within  its  domain  to  de.scribe  the  nature  of  its  data  at  any^poitu.  The  earliest 
data,  “Comparability”  data,  are  the  baseline  comparability  system  (BCS)  estimates  about  the  R&M 
profile  on  the  emerging  system,  The.se  estimates  are  obtained  by  adapting  an  existing  system,  or 
developing  a  composite  of  several  systems,  as  a  best  guess  of  how  the  system  will  perfo'nn  in  the 
field.  The  adjustments  are  performed  by  subject  matter  experts  and  represent  the  impact  of 
technologies  that  have  become  available  since  the  parent  baseline  system’s  parent  system  was 
fielded.  The  BCS  parameters  are  gradually  transformed  into  “Allocated”  R&M  parameters  as  the 
functional  allocation  proceeds,  culminating  in  the  R&M  profile  for  the  baseline  functional  system 
(BFS).  This  proce.ss  allow's  a  more  accurate  R&M  estimate  than  the  BCS  because  the  greaier  deiail 
affords  more  opportunities  to  incorporate  technology  demonstration  data.  Development  of  a 
baseline  physical  system  (BPS)  allows  the  development  of  “Predicted”  R&M  data.  These 
parameters  are  predictions  about  the  implemented  de.sign  based  on  field  data,  reliability  models, 
and  maintenance  task  time  e.stimates. 

There  are  a  number  of  distinct,  but  related,  activities  comprising  R&M.  Failure  .Modes. 

Effects,  and  Criticality  Analysis  (FMECA)  identifies  possible  failures  and  their  as.sociated 
consequences  in  equipment  performance.  FMECA  can  be  performed  on  the  BFS  or  BPS, 

Reliability  Prediction,  the  heart  of  reliability  engineering,  predicts  failure  rates  for  components  of 
sets  of  components.  The  level  of  specificity  for  reliability  prediction  ranges  from  major  systems 
(e.g.,  communications  avionics,  propulsion  system)— generally  performed  by  comparison  with 
fielded  systems— to  additive  approaches  dealing  with  aggregation  and  eviiluation  of  sets  of 
individual  components  (e.g.,  capacitors,  integrated  circuits,  gears).  Between  these  two  extremes  is 
a  variety  of  techniques  that  combine  the  direct  comparison  and  compulation  approaches,  often 
taking  into  consideration  the  effects  of  environment,  configuration,  heat  dissipation,  and  .so  on. 
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Moving  more  into  the  domain  of  maintainability  analysts,  R&M  engineers  eondnct  a 
“Reliability  Centered  Maintenance  Program.”  'Fljis  is  the  determination  of  appropriate  inspection 
procedures  and  intervals,  based  on  FMECA  and  reliability  estimates.  The  purijose  of  this  analysis 
is  to  develop  inspection  requirements  that  keep  equipment  maximally  safe  and  combat-ready  with 
minimum  interference  of  the  peacetime  flying  agenda.  The  inspection  and  periodic  maintenance 
systems  are  said  to  be  subject  to  “Scheduled  maintenance,”  while  other  systems,  including  the 
redundant  systems,  are  subject  to  “unscheduled  maintenance.” 

The  R&M  profile  of  an  emerging  system  is  constrained  by  the  requirements  reliability  in 
two  ways.  First,  to  ensure  the  aircraft  can  successfully  meet  its  mission,  some  low  level  of 
mission  aborts  due  to  mechanical  failure  is  included  in  the  design  goals,  From  the  mission  profile 
and  acceptable  failure  rate,  minimum  reliability  requirements  are  computed  for  the  mission  critical 
systems.  This  reliability  drives  much  of  the  maintenance  demand,  greatly  affecting  maintenance 
concept.  Second,  since  the  average  intersortie  unscheduled  maintenance  time  requirements 
obviously  cannot  exceed  the  time  available  for  maintenance  between  sorties,  system  design 
constraints  are  developed  from  the  mission  scenario  to  limit  intersortie  maintenance,  These 
constraints  are  the  availability  requirements,  which  are  all  .some  variation  of  the  product  of  failure 
rate  and  average  maintenance  time,  divided  by  the  time  between  sorties.  Those  critical  systems  that 
do  not  exhibit  wear  but  rather  fail  randomly — mainly  electronics — are  installed  redundantly  if  their 
continuous  function  is  critical  to  safety;  this  affects  overall  system  reliability.  The  unscheduled 
maintenance  R&M  constraint  is  budgeted  against  these  availability  goals  in  developing  the  R&.M 
profile  for  the  emerging  system.  Maintenance  planning  elaborates  this  maintenance  taxonomy  by 
further  distinguishing  between  on-  and  off-equipment  maintenance.  This  distinguishes  between 
maintenance  that  inhibits  the  preparation  of  the  aircraft  for  further  sorties  fon-equipment)  and  that 
which  does  not  prohibit  further  use  (off-equipment). 

Level  of  Repair  Analysis  determines  where  components  and  subsystems  are  repaired.  The 
exigencies  required  to  produce  high  .sortie  rates  currently  constrain  on-equipment  unscheduled 
maintenance  to  fault  isolation  and  component  replacement  (although  not  always  in  that  order).  This 
reduces  the  problem  to  determining  on-base  versus  off-base  component  repair.  On-base 
component  repair  generally  is  implemented  around  large,  expensive,  temperamental,  general- 
purpose  test  equipment;  that  is,  the  on-  versus  off-base  component  repair  question  is  asked  at  a 
high  level,  early  in  the  system  maintenance  concept  development.  The  problem  centers  on  test 
equipment  cost  versus  additional  sparing  requirements.  Task  time  estimation  is  performed  on 
maintenance  tasks  using  either  comparability  or  industrial  engineering  task  time  computation 
methods.  On-equipment  tasks,  the  critical  element  in  maintaining  a  high  sortie  rate,  are  generally 
comparability-based  design  requirements  with  the  onus  of  a  maintenance  dem.onstration  to 
guarantee  the  design  will  meet  these  requirements. 

Resource  requirement  calculations  within  the  R&M  community  outlined  above  are,  strange 
to  tell,  largely  delegated  to  other  logistic  specialties.  Sparing  is  its  own  unique  province.  The 
current  methodology  for  spares  determination  is  a  multiechelon  probabilistic  model  called  “DYNA- 
METRIC.”  A  fixed  percentage  of  stock  shortages  is  allowed  in  the  overall  maintenance  .scenario 
(referred  to  as  not-mission-capable  supply  (NMCS)  status)  and  the  achieved  availability  is  the 
potential  availability  minus  this  amount.  The  acceptable  shonage  rate,  along  with  shipping  times, 
permits  calculation  of  the  .spares  level  required  at  the  various  supply  locations  defined  for  the 
system.  The  provisioning  community  also  brings  to  the  task  a  great  deal  of  knowledge  about  such 
things  as  contract’ ng  for  spares,  sparing  requirements  across  the  lifetime  of  a  system,  experience 
with  similar  spare  parts,  and  the  national  stick  numbering  scheme.  Calculation  of  support 
equipment  requirements  is  similar,  albeit  simpler.  Some  portion  of  the  not-mission-capable 
maintenance  (NMCM)  time — another  percentage  used  to  translate  potential  availability  to  actual 
availability — is  allocated  to  support  equipment,  and  the  support  equipment  requirements  is 
calculated  for  the  scenario.  Again,  support  equipment  is  a  septirate  specialty  within  logistics. 
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Manpower,  which  will  be  discussed  in  greater  detail  later,  is  calculated  by  the  manpower 
community  against  the  maintenance  scenario.  This  service  has  generally  been  performed  using  the 
BCS  data  by  the  manpower  shop  within  the  acquiring  command,  The  methodology  is  a 
combination  of  a  Monte  Carlo  simulation  (primarily  for  on-equq)ment  maintenance-  typically  70 
percent  of  a  tactical  wing’s  manning)  and  workload  or  workforce-based  standards  for  man\ 
ancillary  function  (e.g.,  management,  precision  measuring  equipment  laboratory  (PMEiL).  training 
management,  supply,  etc.).  It  is  important  to  note  that  the  resource  requirement  calculation  process 
requires  information  about  the  maintenance  scenario  and  operational  requirements,  and  that  all  this 
information  passes  through  the  R&M  community  on  its  way  to  the  responsible  organization. 

Of  particular  interest  is  the  way  maintenance  demand  is  measured  within  the  R&M 
community.  Maintenance  requirements  are  reported  as  maintenance  man-hours  per  flight  hour 
(MMH/FH),  broken  down  by  system  and  maintenance  type.  Some  difficulty  exists  with  this 
metric.  The  translation  from  system  maintenance  requirements  to  AFS  man-hours  is  not  generated 
as  part  of  the  systems  engineering  process  because  this  process  deals  with  hardw'are.  not  actions. 
Thus,  this  translation  is  not  directly  available.  Worse,  accurate  translation  of  .M.MH,/FI1  to 
maintenance  slots  is  not  easily  performed.  The  current  translation  method  is  cumbersome-- 
prohibiting  extensive  and  readily  perfomied  alternative  analysis. 

Maintenance  Planning.  The  independence  of  the  “logistics  and  maintenance  planning” 
activity  in  Figure  2  is  somewhat  misleading.  This  planning  deals  with  R&M  and  operational 
requirements  data,  as  does  R&M,  but  includes  the  maintenance  organization  (i.e.,  which  AFS  does 
the  work  and  how  maintenance  is  organized).  The  important  data  exchanges  within  logistics 
analysis  are  maintenance  requirements  and  times  (from  maintenance  and  logistics  planning  to 
manpower  analysis)  and  manpower-by-AFS  estimated  (to  logistic  planning  activities  that  require 
head  counts  such  as  training,  personnel,  and  facilities). 

Determining  the  AFSs  responsible  for  maintaining  the  various  subsystems  is  hampered  by 
the  existence  of  incompatible  nomenclatures  within  the  acquisition  activity.  The  systems 
engineering  process  assigns  a  hierarchical  identifier  to  each  system  as  its  separate  existence  is 
required  by  the  design  process.  Below  a  certain  level  of  detail  this  identifier  becomes  a  unique 
nomenclature  system  for  the  emerging  weapon  system.  This  identifier  is  termed  the  configuration 
control  number.  Beyond  this,  Logistics  Suppon  Analysis  Record  (LSAR)  data  require  a  unique 
identifier  for  each  of  it's  subsystems  and  each  task  and  resource  associated  with  that  subsystem. 
These  IDs  are  also  unique,  with  interrelations  handled  by  cross-reference.  Although  spaces  are 
provided  on  the  LSAR  C  record  for  work  unit  codes  (WUCs)  and  the  responsible  AFSs,  they  are 
not  used.  Task  identification  is  just  as  tortuous.  The  contractor  will  typically  employ  a  work 
breakdown  structure  of  his  or  her  own  design  to  perform  task  analysis  and  then  develop  a  WUC 
mapping  for  the  system's  tasks  to  translate  tasks  into  the  WUCs.  Also,  items  common  to  several 
systems  require  a  national  stock  number  and  receive  a  contractor  specific  part  identifier,  which  is 
not  compatible  with  the  national  stock  number.  The  upshot  of  this  is  that  there  is  no  simple  data 
connection  among  part  identifiers,  task  identifiers,  and  technician  identifiers  for  a  weapon  system. 
This  is  a  rnajor  hindrance  to  logistics  analysis,  not  to  mention  the  entire  planning  function.  An 
early  identification  of  WUC  and  specialists  associated  with  each  subsystem  entity  would  save 
untold  man-hours  currently  spent  cross-referencing  data  during  logistics  analysis.  Moreover, 
changes  to  the  system  concept  that  affect  manpower  or  any  of  the  logistics  issues  requiring  the 
manpower-by-AFS  statistic  cannot  be  readily  assessed  without  some  sort  of  way  to  translate 
hardware  or  operational  changes  into  WUCs  and  AFS  responsibilities.  Data  elements  exist  in  the 
current  LSAR  definition  to  carry  the  alternative  designators,  but  they  also  are  not  actually  used. 

The  current  manpower  estimation  procedure  generates  a  high-level  comparability  data  base 
using  WUCs  and  AFSs  to  support  a  simulation  study  using  the  Logistics  Composite  Model 
(LCOM).  This  study  estimates  manpower  for  the  initial,  system-level  R&M  and  operational 
requirement  specifications.  These  data  exist  during  the  BCS  manpower  study  and  are  then 


8 


abandoned,  or  more  precisely,  remain  at  the  BCS  level  within  the  idiosyncratic  LCOM  data 
framework.  This  is  another  case  of  incompatible  designators  within  the  acquisition  activity, 
Subsequent  design  data  are  not  subsequently  translated  to  LSAR  for  use  during  system 
development.  The.se  AFS/WUC  data  are  the  foundation  for  the  Training  and  Personnel  Data 
Center  (TPDC)  Crosswalk  program.  The  cross-reference  requirement  has  been  identified 
numerous  times  in  the  pa.st.  The  initial  reference  identified  as  part  of  the  current  effort  is  the 
Coordinated  Human  Resources  Technology  (CHRT)  program,  which  dates  back  to  the  197()s. 

Automation  may  also  help  the  nomenclature  problem.  The  introduction  of  relational  data 
base  notions  to  the  LSAR  world  with  the  release  of  Military  Standard  (MIL-STD)  1388-2B 
(Department  of  Defense  [DoDj,  1991)  may  raise  the  issue  of  conflicting  nomenclatures  within  the 
logistics  community.  Nobody  is  really  interested  in  an  LSAR  control  number  for  its  own  sake; 
The  R&M  community  is  interested  in  subsystem  names,  part  numbers,  and  WUCs;  the  manpower 
and  personnel  community  is  interested  in  manpower-by-AFS;  supply  provisioners  are  interested  in 
the  national  stock  number,  etc.  Currently,  individual  user  communities  are  served  from  the  LSAR 
via  Logistics  Support  Analysis  (LSA)  reports.  The  least  intrinsically  useful  information  on  these 
various  repons  are  the  LSA  control  numbers.  The  relational  data  base  fomtat,  along  with  increased 
computer  use  by  practitioners  of  the  various  logistics  callings,  will  encourage  direct  use  of  the  data 
base  itself  to  tailor  and  generate  specific  reports.  As  the  individual  logistic  communities  will  expect 
to  deal  with  their  customary  indexing  schemes,  we  should  see  increased  demand  for  data  that  can 
be  accessed  by  means  other  than  the  LSAR  control  number. 

A  second  problem  is  the  translation  of  AFS  workload  into  manpower-by-AFS  estimates. 
This  has  been  a  source  of  concern  since  the  1950s.  The  heart  of  the  problem  is  that  manning  needs 
to  be  responsible  to  the  maintenance  demand  distribution,  not  to  average  demand.  No  single  good 
solution  exists,  although  an  LCOM-based  approach,  run  early  in  the  acquisition  to  “validate”  the 
R&M  parameters,  has  been  dominant  for  the  last  two  decades.  Strangely,  the  trade-off  here  is  not 
between  computational  ease  and  accuracy.  Manpower  estimates  made  very  early  can  be  no  more 
accurate  than  the  very  early  subsystem  R&M  estimates  and  maintenance  plans  upon  which  they  are 
based.  For  a  new  design,  this  data  is  not  always  reliable.  Moreover,  a  competent  LCOM-based 
study  requires  many  man-months  of  effort.  The  status  quo  manpower  estimation  situation  can  thus 
be  characterized  as  a  semiaccurate  estimate  made  with  great  difficulty.  This  has  resulted  in  a 
process  where  manpower  does  not  directly  enter  into  the  design  trade-offs. 

Human  Factors  and  Safety 

HF  and  Safety  are  closely  related.  Within  academic  human  factors,  safety  is  viewed  as  a 
subdiscipline;  industrial  engineering  considers  safety  and  human  factors  distinct  subdisciplines 
with  overlapping  curricula.  However,  the  Air  Force  has  separate  offices  responsible  for  human 
factors  and  safety  (and,  perhaps  more  critically,  requires  separate  paperwork  for  each). 
Consequently  defense  contractors  usually  maintain  separate  organizations  for  human  factors  and 
safety,  which  frequently  overlap.  This  close  relationship  is  because  human  factors  and  safety  both 
look  at  the  operation  of  equipment  by  human  beings,  with  safety  concerned  with  potential  hazards 
and  human  factors  focusing  on  all  aspects  of  equipment  operability. 

Not  surprisingly,  their  methods  are  similar,  especially  early  in  the  system  development 
cycle.  Early  safety  analysis  is  grouped  with  early  HF  for  the  present  study  in  that  their  approaches 
to  design  are  similar.  Each  has  a  large  body  of  requirements  that  is  levied  on  an  emerging  system, 
and  each  has  some  form  of  "lessons  learned"  or  catalog  of  previous  mistakes  that  is  scrutinized  for 
wisdom  and  pass  to  the  design  activity.  A  plan  is  developed  to  deal  with  each  HF  and  safety 
problem  identified;  safety  programs  also  demand  a  separate  accounting  of  the  safety  training  for 
each  system.  Note  that  these  general  and  specific  items  are  passed  to  systems  engineering  for 
implementation.  The  disciplines  are  then  on  call  to  aid  the  designers  in  implementing  the 
requirements. 
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HF  is  implemented  by  providing  detailed  design  guidelines  to  ensure  standardized,  usable 
features  for  the  maintenance  personnel.  As  the  design  progresses,  maintenance  requirements  are 
identified,  then  iteratively  refined  and  expanded  to  culminate  in  detailed  descriptions  of  the  system 
maintenance  requirements  that  support  safety  analysis,  task  time  estimation,  and  the  enumeration  of 
requisite  skills  for  each  maintenance  job  classification  projected.  By  and  large  HF  is  forced  into  a 
reactive  posture  by  the  system  development  process.  It  provide.^  guidelines  for  detail  work,  but 
then  must  wait  for  design  to  progress  before  the  suitability  of  the  total  design  can  be  evaluated. 
The  desirability  of  this  practice  depends  solely  upon  how'  effective  the  guidelines  are. 

Both  HF  and  safety  perform  design  evaluations  late  in  the  development  cycle.  HF  is  more 
likely  to  require  demonstrations  of  its  requirements,  while  safety  tends  to  scrutinize  task  analysis, 
training,  and  equipment  design  without  empirical  investigation. 

The  HF  domain  defines  physical  layouts  (e.g.,  size,  mass,  reach  and  vision  limitations, 
etc.);  shape  and  color  conventions  for  displays,  connectors,  controls,  etc.;  and  strength 
requirements  for  various  combinations  of  configuration,  mass,  and  personal  clothing.  The 
purpose  of  this  domain  is  to  limit  possible  design  choices  to  a  range  that  is  within  human 
capabilities  to  operate.  HF  does  very  little  to  affect  the  frequency  or  nature  of  the  tasks  required  to 
maintain  an  aircraft;  these  issues  are  detemiined  by  the  physical  characteristics  of  the  hardware  and 
its  R&M  profiles.  There  is  no  link  between  HF  and  R&M,  except  in  cases  for  which  the  choice  of 
design  alternatives  is  based  upon  the  impossibility  of  humans  performing  maintenance  on  some 
design  alternative. 

A  great  deal  of  recent  interest  has  focused  on  the  use  of  advanced  computer-aided  design 
(CAD)  technology  in  HF.  The  central  notion  is  to  develop  a  computerized  model  of  the  human  and 
use  it  to  test  the  emerging  design  against  human  capabilities  within  the  CAD  environment.  There  is 
still  a  lot  of  maturation  required  in  this  technology,  but  it  shows  tremendous  potential.  From  the 
point  of  enhancing  the  status  quo  HF  process,  it  may  permit  the  development  of  more  accurate 
design  guidelines  and  permit  a  proactive  dialog  with  the  equipment  physical  layout  activity.  The 
use  of  this  technology  to  verify  task  analysis  or  technical  orders  by  parsing  these  data  and 
performing  the  requisite  activities  is  possible,  although  a  better  plan  might  be  to  use  portions  of  the 
man-model  technology  to  author  detailed  task  sequences  in  support  of  manual  task  analysis  and 
technical  order  development. 


The  success  of  the  systems  engineering  strategy  is  due  to  the  decomposable  nature  and 
clear  understanding  of  the  part/whole  relationships  of  the  primary  engineering  parameters.  For 
example,  consider  weight.  A  total  airframe  weight  is  estimated  and  budgeted  among  the 
subsystems  based  on  experience  with  similar  systems,  predictions  of  weight  for  subsystems 
employing  new  technology,  typical  weight  growth  experienced  by  other  development  efforts,  and 
so  on.  As  the  design  is  either  further  functionally  allocated  or  when  the  hardware  design  is 
underway,  more  accurate  subsystem  weight  estimates  become  available.  If  a  system  is 
overweight,  the  impact  on  system  parameters  of  performance,  payload,  range,  etc.,  is  readily 
calculated  and  the  decision  to  accept  the  discrepancy,  trim  the  allocated  weight  from  other 
subsystems,  or  build  a  slightly  larger  aircraft  can  be  rationally  made.  Needless  to  say,  the  choice 
betw'een  the  preferred  option  and  one  of  the  latter  two  is  also  strongly  determined  by  the  cost  of  the 
redesign  effort  in  manpower  and  schedule. 

The  length  of  the  data  dependency — from  design  description  to  R&M  parameters,  to 
manpower,  to  training,  and  finally  to  personnel — affects  how  well  the  systems  engineenng  design 
process  works  with  respect  to  these  issues.  The  first  bottleneck  is  reliability.  Reliability  prediction 
undergoes  a  quantum  precision  change  in  moving  from  a  comparability  approach  dealing  with 


subsystems  to  reliability  prediction  over  the  actual  design  layout.  At  the  point  where  reiiabiliiy 
information  from  the  hard  design  is  available,  the  cost  of  compensating  redesign  is  often 
prohibitive.  To  compensate  for  this  unavoidable  trade-off  between  detail  and  fle.xibility,  much 
support  is  available  for  reliability  improvement  within  a  given  design,  and  some  otherwise 
unallocated  reliability  budget  is  kept  available  to  handle  these  problems.  Thus,  assessing  the  .MP'l’ 
implications  of  reliability  fluctuations  is  avoided  by  the  advance  of  reliability  engineering  w  iihin  the 
design  specialties. 

The  reliability  profile  directly  affects  the  ability  of  the  emerging  system  to  accomplish  the 
sorties  or  achieve  the  requisite  sortie  rate.  Therefore,  reliability  is  a  hard  design  constraint. 

I  Moreover,  the  relationships  between  reliability  and  sptires  cost,  maintenance  concept,  M.MH/FH, 

and  number  of  airframes  required  to  fulfill  the  mission  are  well-known  and  readily  assessable  at 
any  phase  of  the  development  effon  to  provide  a  good  approximation  of  the  impact  of  a  reliability 
deficit.  Because  reliability  serves  as  a  hard  system  constraint  and.  after  all,  one  can  always  add 
more  manpower,  adding  an  exact  MPT  calculation  may  perhaps  only  add  a  third  significant  digit  to 
the  cost  impact  estimates  of  non-debilitating  reliability  deficits.  Thus,  the  MPT  community  is  often 
asked,  "What  difference  does  MPT  make?" 

Missing  from  this  point  of  view  is  the  ability  to  assess  the  impact  of  deficient  or  surplus 
reliability  on  MPT  issues;  manpow'er  is  fixed  by  the  early  manpower  study  and  treated  as  a  fixed 
attribute  of  the  emerging  system.  To  optimize  a  system,  the  ability  to  calculate  the  impact  of  R&.M 
concept  or  task  time  changes  of  each  portion  of  the  system  is  a  prerequisite.  Thus,  a  reliability 
deficit  would  be  compensated  for  by  selecting  the  portion  of  the  system  in  which  reliability  growth 
would  provide  the  maximum  MPT  return.  Reliability  improvement  opportunities  could  be 
assessed  against  the  same  criteria.  This  requires  input  from  the  MPT  community  which  will  allow 
designers  to  assess  the  impact  of  MPT  as  easily  as  the  impact  of  spares  and  other  cost  drivers  are 
computed.  This  is  a  difficult  challenge,  because  MPT  is  an  inherently  more  complex  arena  within 
which  to  make  trade-offs  than  are  reliability  or  sparing  versus  maintenance  concept  decisions. 

The  reliability-to-MPT  bridge  is  also  the  point  at  which  changes  to  the  mission 
requirements  impact  MPT.  Inasmuch  as  development  efforts  take  more  than  a  decade,  the 
requirements  underpinning  the  entire  effort  often  change  over  time.  Numerous  trade-offs  exist 
between  the  mission  requirement  and  the  ultimate  characteristics  and  number  of  the  system  being 
developed.  Unfortunately,  many  changes  to  mission  requirements  change  the  emerging  system 
greatly  in  ways  that  affect  aircraft  logistic  requirements.  Thus,  the  entire  logistics  analysis  cycle 
must  begin  again  with  each  change  to  the  mission  definition.  The  current  acquisition  process  tends 
to  lockstep  the  analysis  into  fixed  phases,  with  feedback  from  changes  to  the  mission  not  affecting 
logistics  planning  until  the  next  phase.  This  is  another  way  of  saying  that  logistics  analysis 
depends  upon  a  fixed  mission  scenario.  The  length  of  time  between  initial  system  definition  and 
fielding  of  the  system  means  that  much  of  the  early  logistics  analysis  should  be  concerned  with 
ranking  options  in  ways  that  make  the  resultant  design  and  its  logistic  characteristics  fiexible  to 
change  rather  than  providing  accurate  estimates  of  exact  .system  performance.  It  is  mainly  later  in 
the  acquisition  cycle,  when  the  mission  and  configuration  of  the  system  will  not  change 
significantly,  that  precise  estimates  are  required  so  support  the  acquisition  of  support  materials  and 
for  MPT  planning.  Early  in  the  process,  knowing  that  one  alternative  is  favorable  to  another  is 
often  sufficient. 
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Eiirlv  Manpower 


Early  MPT  is  primarily  the  estimation  of  manpower-by-AFS  for  a  weapon  system.  The 
manpower-by-AFS  statistic  may  subsequently  be  used,  along  with  the  AFSs'  training  and  career 
progression  information,  to  calculate  system  life-cycle  cost.  Notably,  "manpower-by-AFS"  is  the 
metric  of  the  MPT  community.  The  manpower-by-AFS  statistic  is  the  bridge  between  the 
engineering  community's  MMH/FH  and  much  of  the  logistics  community.  This  stems  I'rom  the 
fact  that  logistics  planning  is  on  a  per  head  rather  than  a  per  flight  hour  basis.  Examples  of  this  are 
training  and  facilities:  While  such  statistics  as  "hours  of  maintenance  training  per  flight  hour"  or 
"food  service  volume  per  flight  hour”  are  calculable,  they  would  be  useless  within  the  training  and 
facilities  planning  communities.  "Training  requirements  per  person"  and  "meals  served  per  day" 
tu'e  useful  statistics  to  the  training  and  facilities  communities,  and  these  figures  require  manpower- 
by-AFS  in  their  calculation. 

Still,  there  is  no  contextual  difference  among  maintenance  planning,  R&M,  and  manpower. 
Maintenance  type,  times,  frequencies,  skill  requirements,  crew  size,  and  equipment  requirements 
are  the  fundamental  data  of  the  manpower  estimation  process.  Clearly,  manpow'er  analysis  can  be 
performed  as  part  of  R&M  and  maintenance  planning. 

Late  Manpower 

There  is  no  “late  manpower”  w  ithin  the  acquisition  cycle  because  manpow'er  estimates  do 
not  routinely  change  during  the  cycle.  However,  the  last  few  years  have  seen  a  change  in  the 
Department  of  Defense  50(X)  series  requirements  and  manpower  estimates  are  now'  required  at 
Milestones  2  and  3.  It  is  possible  that  this  requirement  will  motivate  the  acquisition  community  to 
keep  some  form  of  direct  manpow'er  estimation  data  base  active  thioughout  the  acquisition  cycle. 
This  is  not  currently  done. 

Training 

Training  planning,  occurring  at  the  earliest  phases  of  system  development,  deals  with 
detemtining  training  requirements  to  meet  personnel  requirements  and  addresses  the  particulars  of 
transition  training  to  ensure  maintenance  readiness  for  the  new  system  w'hen  it  is  fielded.  When 
new  training  requirements  are  generated  by  the  new  system,  these  requirements  are  documented 
and  planning  is  instituted  to  include  the  new  material  in  the  existing  training  courses. 

Early  Resource  Quantification 

The  number  of  recruits  going  through  the  various  maintenance  curricula  is  currently 
tracked.  Consideration  of  training  within  the  acquisition  cycle  currently  identifies  the  impact  of  the 
new  system  on  the  training  activity  and  identifies  the  number  of  personnel  required  to  form  a 
training  cadre  for  maintenance  and  operations  (i.e.,  aircrew  training). 

Training  Course  Development 

Training  curriculum  is  developed  and  maintained  according  to  Air  Force  Manual  50-2, 
Instructional  System  Development  (ISD)  Process  (DAF,  1986).  This  is  a  systems  approach  to 
training  which  analyzes  the  requirements  and  jointly  develops  training  objectives  and  associated 
criterion-referenced  (mastery)  tests.  The  training  courses  are  reassessed  during  the  final  stages  of 
the  development  process,  transitional  training  is  developed,  and  the  initial  training  courses  are 
adjusted  according  to  the  demands  of  the  new  system. 
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In  the  preceding  paragraphs,  "personnel"  refers  to  the  act  of  determining  the  nutTiber  o! 
qualified  accessions  required  to  meet  the  end  strength  requirements  set  by  the  emerging  system's 
schedule  and  its  rnanpower-by-AFS  requirements.  Personnel  also  deals  with  tailoring  enlisted 
specialties  to  meet  the  Air  Force  enlisted  workload.  The  "AFS  structure '  is  the  collection  of 
specialties  and  associated  career  paths  in  which  enlisted  maintenance  personnel  participate  during 
their  Air  Force  career. 

The  personnel  system  also  track.s  the  career  progression  of  the  various  AFSs.  This  entails 
incorporation  of  numbers  required  in  the  fielded  force,  training  times,  and  retention  data  into  a 
model  to  estimate  the  recruits  necessary  to  man  a  new  system.  As  retention  rates  vary,  the  force 
could  end  up  with  wrong  proponions  of  senior/intermediate/junior  personnel  in  the  maintenance 
environment.  This  aspect  of  the  personnel  domain  is  managed  by  selective  reenlisiment  bonuses, 
mid-career  AFS  changes,  and  early  retirements. 

A  new  system  is  manned  by  the  maintenance  structure  and  organization  of  the  system  it 
replaces.  Thus,  the  personnel  community  requires  manpower-by-AFS  estimates  for  early 
recruitment  planning.  The  earlier  these  are  available  the  better  because  changes  to  the  force 
population,  and  to  the  recruited  population,  can  then  be  implemented  smoothly.  To  aid  this,  a  ten- 
year  projection  of  the  number  of  potential  recruits  in  the  general  population  is  developed  and 
updated  quarterly. 

One  frequently  voiced  concern  about  the  status  quo  of  the  AFS  structure  is  that  it  may  be 
over  specialized.  The  drawback  of  narrow  .specialization  is  that,  in  meeting  the  peak  manning  to 
cover  the  unscheduled  maintenance  of  a  nonuniform  .sonie  .schedule,  narrow  specialties  tend  to  be 
utilized  less  fully  than  a  more  broadly  responsible  AFS  structure.  On  the  other  hand,  narrov. 
specialties  require  less  training  than  broad  specialties,  resulting  in  lower  overhead  because  fewer 
people  are  in  the  training  pipeline  to  fulfill  future  maintainer  requirements.  The  optimal  AFS 
structure  balances  the.se  two  effects  (along  with  other  constraints  such  as  availability  of  facilities 
and  recruit  characteristics)  to  minimize  costs  while  fulfilling  the  maintenance  requirements.  The 
matter  of  recombining  AFSs  to  form  an  optimal  AFS  structure  has  recently  come  to  the  fore.  This 
activity  is  called  "AFS  restructuring." 

Two  different  approaches  to  AFS  restructuring — 1)  the  Air  Force  Armstrong  Laboratory- 
Logistics  Research  Division’s  Small  Unit  Maintenance  Manpower  Analysis  (SUMMA)  and 
derivative  Specialty  Structuring  System  (S^)  projects;  and  2)  the  Rivet  Workforce  initiative — have 
occurred  within  the  last  five  years.  SUMMA  and  developed  and  extended  an  analytic 
framework  which  breaks  down  a  target  system’s  maintenance  workload  into  homogeneous  task 
groups.  These  chunks  are  then  clustered  into  a  new  AFS  structure.  Training  requirements  are 
calculated  by  prorating  the  parent  AFS's  training  requirements  against  that  AFS's  portion  of  the 
individual  task  clusters,  then  applying  these  prorated  training  times  to  the  reassembled  AFSs  based 
upon  the  new  AFS's  task  re.sponsibilities.  The  Rivet  Workforce  approach  was  to  have  subject 
matter  experts  restructure  AFSs,  without  quantitative  modeling.  The  Rivet  Workforce  effort 
produced  a  revised  aircraft  maintenance  AFS  structure,  combining  a  number  of  formerly 
independent  AFSs.  Given  the  lack  of  established  analytic  approaches  in  this  tirea,  this  was  not  a 
bad  approach. 

Another  potential  adjustment  to  the  existing  personnel  system  is  tailoring  an  AFS  structure 
to  particular  weapon  systems,  or  "closed  looping."  The  modern  Air  Force  has  preferred  not  to 
close  loop  maintenance  personnel  throughout  its  history  .so  that  the  force  could  adapt  easily  to  a 
new  weapon  system  and  could  allow  personnel  a  wider  range  of  career  paths.  During  the  period  of 
rapid  system  obsole.scence  of  the  I950.s  and  1960s-— the  era  of  the  century  .series  fighters — this 


made  a  great  deal  of  sense.  In  the  modern  era,  though,  front  line  systems  are  expected  to  remain 
on-line  for  longer  periods  than  was  formerly  possible.  This  makes  tailoring  enlisted  maintenance 
career  paths  to  specific  aircraft  more  attractive.  Closed  looping  flightline  personnel  could  support 
emerging  operational  concepts-notably  single  squadron  and  composite  wing  deployments--by 
providing  more  broadly  responsible  AFSs  without  increasing  the  training  overhead  for  those 
troops.  While  some  discussion  of  closed  looping  and  composite  wing  operations  is  noted  in  the 
literature,  no  quantitative  assessment  of  the  savings  possible  in  manpower,  personnel,  or  training 
costs  for  these  options  was  uncovered  during  the  present  effort. 

"Personnel”  also  includes  the  recruiting  process.  The  aptitude  of  ascessions  (recruits)  is 
classified  by  critical  subscores  from  the  Armed  Services  Vocational  Aptitude  Battery  (ASVAB). 
The  recruiting  burden  is  couched  in  tenns  of  the  number  and  distribution  of  accessions  required  for 
a  particular  purpose.  Personnel  models  estimate  the  feasibility  and  cost  of  attaining  a  population  ot 
accessions  that  meet  the  target  number  and  population.  Planning  in  personnel  consists  of 
determining  the  accession  rate  to  fulfill  the  maintenance  technician  requirement,  given  the  training 
length  and  success  rate,  and  assuring  that  the  career  progression  is  appropriate  in  providing 
appropriate  numbers  of  suitably  experienced  senior  personnel  for  maintenance  supervision  later  in 
their  careers. 


Figure  3 

Personnel  and  Training  Feedback  Process 
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Personnel  and  Training  Feedback  Processes 

Determination  and  adjustment  of  personnel  aptitude  requirements  foi  each  AFS  is  through 
indirect  feedback  from  field  maintenance  management  through  the  training  process.  Figure  3 
presents  the  flow  of  infonnation  in  this  process.  If  the  performance  of  new  field  technicians  is 
deemed  unacceptable,  the  deficiency  is  reported  to  the  training  community  for  rectification.  Two 
responses  are  possible;  Field  Training  Detachments  may  provide  supplementary  training  to 
personnel  in  the  field  or  a  change  in  the  training  school  curriculum  may  be  instituted  for  the 
affected  AFSs.  If  the  course  material  is  not  being  absorbed  by  the  recruits  in  an  acceptable 
fashion,  training  might  be  restructured  or  lengthened.  The  problem  might  also  lead  to  an 
adjustment  of  the  minimum  ASVAB  qualification  score  requirements.  In  practice,  the  actual  cut¬ 
off  score  is  already  higher  than  the  minimum  acceptable  score  for  recruits.  This  was  presumably 
done  to  exploit  a  favorable  selection  ratio. 

Thus  there  is  no  predictor/criterion  data  base  which  directly  validates  the  A.SVAB.  Rather, 
the  ASVAB  employs  a  content  validation  approach,  with  the  cutting  scores  determined 
experientially  rather  than  p.sychometrically.  Empirical  validation  of  the  formal  selection  instrument 
is  against  the  training  curriculum  and  training  success  rates  are  used  for  the  dependent  variable  to 
validate  the  .selection  battery. 

The  lack  of  data  poses  a  problem  for  AFS  restructuring  because  analytic  paradigms  w  hich 
can  be  u.sed  to  evaluate  candidate  alternative  AFS  .structures  require  data.  First,  the  minimum  cut¬ 
off  scores  are  typically  lower  than  the  actual  cut-off  score  used,  which  is  determined  by  selection 
ratio — the  ratio  of  the  applicants  available  to  the  recruits  needed.  Second,  the  demand  distribution 
for  AFSs  varies,  consuming  some  potential  accessions  with  higher  scores  by  placing  them  in  AF'Ss 
for  which  they  are  overqualified.  Next,  if  the  demand  for  maintainers  is  sufficiently  strong, 
marginal  recruits  are  helped  through  training  by  extra  practice,  tutoring,  etc.  Finally,  the 
qualification  feedback  system  described  is  not  precise  enough  to  distinguish  among  related  AFSs. 
Thus,  ASVAB  Electronics  subscale  standards  for  all  avionics  and  electronic  specialists  is  around 
the  8()th  percentile,  with  no  distinction  made  among  the  specialties  by  the  personnel  system. 

Manpower.  Personnel,  and  Training  Integration 

The  Air  Force  recently  introduced  yet  another  integrated  MPT  effort,  the  '‘Integrated 
Manpower,  Personnel,  and  Comprehensive  Training  and  Safety"  or  IMPACTS.  It  is  widely 
believed  that  logistics  was  integrated  and  that  MPT  were  two  elements  of  the  current  scheme  of 
integrated  logistics,  called  “Integrated  Logistics  Support"  or  ILS.  The  major  impact  of  I.MP.ACTS 
appears  to  be  the  generation  of  an  integrated  MPT  plan  that  is  largely  redundant  with  the  existing 
Integrated  Logistics  Support  Plan  (ILSP)  but  will  be  read  by  fewer  people.  The  bureaucratic 
edifice  surrounding  this  new  integration  effort  will  only  serve  to  further  separate  MPT  from  its 
R&M  underpinnings  in  the  system  design  process.  This  is  a  giant  .step  in  the  wrong  direction. 
The  Air  Force  should  be  moving  toward  greater  integration  of  the  various  logistic  areas,  not  tow  ard 
greater  fragmentation.  This  is  the  point  of  recent  concepts  such  as  CE  and  the  Computer-aided 
Acquisition  and  Log’stics  Support  (CALS)  initiative. 

Historical  Perspective 

Integrated  MPT  has  been  tried  before.  Initial  development  of  an  integrated  MPT 
management  concept,  the  Personnel  Subsystem,  occurred  in  the  late  195()s.  It  was  developed  as 
part  of  the  then-emerging  systems  engineering  concept  and  contained  MPT,  Training  Materials 
Development,  HF,  and  safety.  It  was  overshadowed  by  development  of  integrated  logistics  in  the 
early  196()s,  and,  admittedly,  lacked  a  suitable  array  of  tools  to  Integrate  its  special  issues  with 
system  design.  The  next  MPT  integration  effort,  CHRT,  was  devoted  to  developing  suitable  tools 
to  incorporate  MPT,  Training  Materials  Development,  HF,  and  safely  into  the  desigti  process. 
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CHRT  culminated  in  a  series  of  underwheltning  demonstrations  of  its  methodologies  !e.g  , 
Askren,  ei  al.,  1976).  The  basic  concepts  of  CHR"’’  were  picked  up  by  the  Navy  as  their 
HARDMAN  project,  the  kernel  of  which  still  exists  as  HARDMAN  111  and  IV.  The  Amiy  and  .Air 
Force  both  expressed  interest  in  HARDMAN;  this  interest  culminated  in  the  Army  MANPRINI 
project  in  the  mid-l98()s.  By  this  time,  MPT  integration  had  progressed  to  the  higher  science  of 
mapping  out  the  acquisition  documents  and  requirements  that  must  be  included  in  a  major  system 
acquisition,  leaving  behind  the  mundane  methodological  concerns  that  plagued  earlier  .MPT 
integration  efforts.  The  Air  Force  considered  directly  adapting  .MANPRINT,  but  decided  instead 
to  invent  their  own. 

Integrated  Manpower.  Personnel,  and  Consolidated  Trainintt  System 


Figure  4  represents  the  logistic  areas  relevant  to  MPTS  issues,  I'he  abscissa  represents  the 
flow  of  an  acquisition  process  over  time  the  arrows  represent  the  major  Hows  of  infomiation.  'fhe 
enclosed  area  is  the  MPTS  domain  as  defined  for  IMPACTS.  The  striking  feature  ol  this  is  the 
exclusion  of  maintenance  planning  and  R&M.  This  reinforces  the  existing  distinction  among 
logistic  domains  and  the  partitioning  of  resource  estimation  activities  from  those  that  provide  their 
data  .sources. 


Figure  4 

Traditional  Integrated  MPTS 

The  question  arises.  “Integration  MPT  for  what  purpose'.^’’  The  .MPT  domain  is  not 
independent  from  the  R&M  and  maintenance  planning  activities;  therefore,  the  answer  cannot 
logically  be,  “To  make  the  design  more  responsive  to  MPTS  issues.”  Imposing  a  supplementary 
bureaucratic  edifice  upon  an  already  unresponsive  system  is  not  a  good  solution  to  the  problem  of 
unresponsiveness.  A  better  solution  is  to  make  MPT  issues  a  more  integral  part  of  the  more 
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fundamental  engineering  and  logistic  domains.  I'his  is  no  longer  a  management  issue  or  a  case  ot 
the  logistics  community  being  ignored.  1'he  .Manpower  Estimate  Report  (.MER)  rcLjuircmenls. 
even  if  there  were  no  prospect  for  increased  efficiency,  has  tlirust  MP'f  into  the  center  of  the  design 
process.  This  is  now  a  technology  issue;  there  is  no  good  way  to  remove  the  barriers  between  the 
logistic  domains,  and  these  barriers  are  the  cau.se  of  the  oft-cited  unresponsiveness  of  dc.sigti  to 
these  issues. 

in.  AN  ALTERNATIVE  SCHEME  OF  LOGIS  HC  i.N  TEGRATION 

Figure  5  presents  an  alternative  scheme  to  integrated  logistics.  The  larger,  shoe-.shaped 
area  in  the  left  of  the  figure  ts  temied  the  I.x)gistics  Resource  Requirements  activity.  It  deals  with 
developing  early  R&M  parameters  and  provides,  in  addition  to  the  usual  R&M  metrics,  manpower- 
by  AFS  estimates  as  w'ell  as  the  training  and  personnel  requirements  txcessary  to  support  the 
manpower-by-AFS  profile.  The  focus  of  the  proposed  effort  is  to  develop  a  single  workstation  to 
address  all  of  these  issues.  This  facility  leads  eventually  to  the  development  of  cost  estimates 
based  on  MPT  issues  as  part  of  the  early  R&M  activity.  The  cost  estimates  become  the  basis  for 
trade-offs  among  R&M  and  MPT  factors  within  the  design  activity. 


Figure  5 

Alternative  Grouping  of  Logistic  Domains 


HF  and  safety  are  removed  from  MPT:  both  HF  and  MPT  are  unaffected  by  this  change 
because  the  domains  do  not  overlap.  Since  the  integration  scheme  proposed  for  this  effort  is  an 
integrated  logistics  analysis  tool  and  the  data  base  is  an  extension  of  LSAR,  comparability  and 
allocation  portions  of  R&M  are  co-opted  within  the  Logistics  Resource  Requirements  activity.  The 


iloul  IS  lo  produce  an  R&M  aianageiueiu  daia  base  interi'acc  tor  R&M  purposes  and  iniceraie  iliis 
With  the  other  raaintenance  planning  and  MPT  issues.  The  change  in  RiltM  is  that  maintenance 
inanpovver-by-AFS  and  MFl  cosi  statistics  will  be  included  in  the  R&M  reports. 

Not  shown  in  Fiuure  5  is  a  new  data  link  between  the  maintenance  task  idcntiiication  and 
the  two  training  bo.xes.  "The  integration  proposed  here  is  between  the  training  objecti'  e:,  ;:t  !S1J 
and  the  tasks  that  these  support.  In  addition  to  integrating  ISD  with  l.SA,  this  linkage  torms  the 
basis  for  evaluating  alternative  AFS  structures  in  light  of  both  manpower-bv-AFS  and  u-atnmg  and 
personnel  burden. 

Tne  duck-head  shaped  area  on  the  right  side  of  the  figure  is  tilled  the  ■integrated  'I'ask 
Analysis  Products”  section.  Combine  these  activities  into  a  single  prtx-ess  would  lx  facilitated  in 
chances  to  the  LSA  and  ISD  prtxesses  developed  by  the  proposed  effort,  although  this  is  outside 
Its  scope. 
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IV.  ISSUES  IN  INTEGRATED  MANPOWER.  PERSONNEL,  AND  TRAiNiNG/ 
RELIABILITY  AND  MAINTAINABILITY  ANALYSIS 

Phase  II  will  implement  and  verify  an  integrated  supportability  analysis  and  irade-oK  tool. 
Phase  1  identifies  compensatory  relationships  among  the  operational,  R&M,  and  MPT  domains, 
described  in  detail  below.  Another  portion  of  this  effort  is  previous  work  on  the  relationship 
between  R&M  and  MPT  analyses. 

If  successful,  this  effort  will  demonstrate  an  integrated  logistics  resource  requirements  too! 
for  MPT  and  R&M  issues  suitable  for  use  in  the  systems  engineering  and  logistics  communities 
during  system  development.  The  approach  will  allow'  the  currently  unaddressable  issues  of 
training  impact  and  AES  structuring  to  fall  under  the  control  of  project  management  during  system 
development.  This  will  provide  increased  ease  and  timeliness  in  evaluating  the  trade -tiffs  among 
the  logistic  and  design  parameters.  Possible  follow-on  work  will  include  expanding  the  system  to 
a  Class  2  LSAR  automation  tool  as  a  basis  for  future  services  to  government  and  industry. 

Top-Down  Systems  Tool  for  Logistics  Baseline  and  .Modifications 

The  successfully  completed  Top-down  Systems  Tool  for  Logistics  (TDSTL)  project  is  a 
loosely  connected  group  of  three  efforts  that  sought  to  provide  a  means  to  apply  systems 
engineering  principles  of  functional  allocation  and  succe,ssive  refinement  to  .MFF  issues.  The  first 
of  these  efforts  produced  a  process  and  data  model  which  divides  MPT  analysis  into  standard 
categories  and  identifies  design  measures  of  merit  gennane  to  the  MPT  domain  (.Miller  &  Bovle. 
1991). 


The  Integrating  Manpower  Analysis  with  Computer-aided  Design  (l.MACAD)  effort-  the 
second  in  this  serie.s — developed  an  approach  and  software  demonstration  for  allocating  and 
monitoring  manpower-by  AFS  during  system  development  in  place  of  the  current  practice  i>f 
allocating  and  monitoring  R&M.  The  advantage  of  this  approach  is  that,  singe  .Mviu/Fll  is  a 
difficult  statistic  to  translate  into  manpower  slots,  meaningful  trade-offs  between  R&M  and  other 
logistics  and  operational  considerations  may  be  facilitated  by  looking  at  the  manpower  skgs  direciK 
rather  than  proxying  the  measure  with  maintenance  man-hours. 

The  final  TDSTL  effort  refined  the  IMACAD  software  product  by  streamlining  the 
interfaces  and  adding  W'ork  center,  mixed  mission  analysis,  .sensitivity  analysis,  indirect  lalx:>r.  and 
cost  analysis  facilities  to  the  basic  structure,  A  revised  data  set,  against  which  these  features  were 
validated,  was  developed  and  includes  these  new  features.  The  effort  also  traces  the  evolution  of 
F-16  R&M  development  and  documents  the  di.sas.sociation  of  the  manpower  ra|uirement.s  from  the 
R&M  process. 

The  manpower  calculation  scheme  has  two  aspects.  First,  all  direct  maintenance  work  is 
clas.sed  as  scheduled  or  unscheduled  and  on-equipment  or  off-equipment,  or  as  indirect  labor.  On- 
equipment  tasks  are  also  classified  by  whether  they  impede  the  use  of  the  aircraft  for  a  sortie  or 
sortie  preparation  activity.  Second,  manpower  is  calculated  for  each  AFS  at  each  work  center  in 
three  ways:  The  largest  of  these  is  taken  as  the  manpower  estimate.  One  of  the  three  manpower 
estimators  is  to  consider  the  sortie-impeding  W'ork  (generally,  on-equipment  work)  as  a  queuing 
problem  against  the  system  availability  requirement,  with  Number  of  Crews  times  Average  Crew 
Size  times  Number  of  Shifts  as  the  manning  (Peak  Manning).  The  second  estimate  is  to  man  for 
all  the  workload  against  manpower  availability  and  shift  policy  (Workload  Manning),  d'he  thiixi 
method  is  to  man  to  meet  the  task  with  the  largest  crew  size  requirement,  considering  shift  fiolicy 
(Max  Crew  Manning).  This,  essentially,  handles  the  LCOM  manning  which  is  about  70  percent  of 
a  tactical  wing  complement.  Additional  manning  strategies,  based  on  manning  standards,  are  also 
available  to  complement  this  strategy. 
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The  final  software  produced  acceptably  accurate  manpower  estimates.  Interested  readers 
should  obtain  a  copy  of  the  final  report  (Miller,  in  press).  The  data  base  from  that  study  needs 
expansion  for  the  current  effort.  Also,  the  system  still  needs  development  of  the  user  interlaces  to 
support  the  various  communities  in  the  Logistic  Resource  Re(.)uirements  domains.  Nonetheless, 
the  demonstration  showed  that  Manpower  can  lx*  integrated  with  R&M  data  management  and  this 
provides  a  solid  basis  for  the  current  effort. 

Several  improvements  in  the  system  are  potentially  beneficial.  The  major  improvement 
w'ould  be  increased  ability  to  manipulate  and  analyze  information  at  the  work  center  level.  This 
would  permit  more  control  over  such  things  as  crew  composition  and  shift  policy,  and  would 
allow  work-center-by-work-center  manpower  analysis — as  opposed  to  analyzing  the  entire  w  ing  or 
operating  location  data  base — which  would  pemiit  a  more  detailed  analysis  without  undue  delay  in 
obtaining  results. 


Manpow'er,  Personnel,  and  Training  Integration  Issues 

The  current  approach  is  to  treat  .MPT  as  a  part  of  R&M.  'I'he  interrelationships  among 
MPT  issues  tu-e  complex.  Furthermore,  data  and  methods  are  either  unavailable  to  the  acquisition 
process  or  nonexistent  for  many  of  the  potential  trade-offs. 

This  section  catalogs  MPT  data  and  what  is  known  about  relationships  among  .MFL  issues. 
Well-understood  relationships  are  tho.se  for  which  there  are  models  or  data  that  quantitatively 
explicate  MPT  resource  requirements  and,  often,  the  manner  in  which  one  resource  can 
compensate  for  another.  For  example,  the  relationship  between  manpower  and  maintenance 
concept  is  well  understood  in  that  the  direct  maintenance  man-hours  for  various  maintenance 
concepts  can  be  calculated  and  from  this,  manpower-by-AFS  can  be  derived.  On  the  other  hand, 
the  relationships  among  AFS  structure,  training  time  requirements,  and  personnel  aptitudes  are 
unknown  beyond  the  nonqualitative  notion  that  broader  AFSs  should  require  individuals  w  ith 
higher  aptitudes  and/or  longer  training  times.  Also,  for  the  sake  of  this  discussion,  details,  on-the- 
job  training  (OJT),  and  management  tasks  are  considered  part  of  the  maintenance  workload. 

Well  Understood  Relationships 

Reliability  vs.  maintenance  demand 

Mission  requirements  vs.  maintenance  demand 

Maintenance  times  vs.  maintenance  demand 

Maintenance  concept  vs.  maintenance  demand 

Maintenance  demand  vs.  maintenance  manpower-by-AFS 

Maintenance  manpower-by-AFS  vs.  maintenance  task  responsibility  for  each  AFS 

Maintenance  manpower-by-AFS  vs.  training  requirements 

.Maintenance  manpower-by-AFS  vs.  required  accessions  per  year 
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Maintenance  task  demand  (reliability)  by  AFS  and  work  center 
Maintenance  task  times  by  maintenance  concept 

Details,  OJT,  and  management  task  requirement  by  AFS  and  work  center 

Attririon  rates  per  year  by  AFS 

Career  progression  steps  and  times 

Maintenance  task  responsibility  for  each  AFS 

Training  times  by  AFS 

Variable  and  fixed  costs  by  year  of  service  for  manpower 
Training  costs 

Accession  costs  by  AFS  requirements 
Other  personnel  costs 

Well  understood  issues  are  those  that  deal  with  assessing  the  MPT  requirements  and  cost^ 
for  a  fixed  AFS  structure  (maintenance  task  responsibility  for  each  AFS).  Because  of  the  data 
assembly  and  calculation  problems  discussed  above,  the  most  troublesome  step  is  convening 
R&M,  etc.,  into  manpower-by-AFS  estimates.  The  manpower-by-AFS  implications  of  a  new 
AFS  structure  can  also  be  assessed  once  task  responsibilities  are  apportioned  among  the  new 
AFSs.  The  implementation  of  a  facility  to  integrate  this  set  of  MPT  functions  with  the  R&M 
process  was  the  accomplishment  of  three  pres  lous  SEI  effons;  IMACAD,  TDSTL.  and  TDS'FL  11. 

Poorly  Understood  Relationship.^ 

Training  times  vs.  personnel  aptitudes  by  AFS 
Trainiiig  times  vs.  maintenance  task  responsibility  for  each  AFS 
Personnel  aptitudes  vs.  maintenance  task  responsibility  for  each  AFS 
AFS  career  progression  vs.  maintenance  task  responsibility  for  each  AFS 
Attrition  level  vs.  maintenance  task  responsibility  for  each  AFS 

Ancillary  Data  to  Make  Trade-offs  Over  These  Relationships 

Training  block  required  for  each  maintenance  task 
Personnel  aptitude  requirements  by  AFS 
Training  times  by  training  block 
Training  blocks  in  curriculum  by  AFS 

A  clearer  view  of  these  poorly  understood  relationships  is  necessary  to  as.sess  the  MPT 
impact  of  AFS  restructuring  adequately.  Without  an  adequate  understanding  of  the  implications  of 
AFS  restructuring  on  aptitude  and  training  time  requirement.s,  a  le.ss  efficient  or  even  unfeasible 
AFS  structure  may  be  devised. 

The  major  objective  of  the  propo.sed  effort  is  to  develop  and  validate  a  methodology  for 
AFS  structure  optimization  within  a  single  weapon  system  and  to  estimate  the  improvement  this 
alternative  structure  will  afford  over  a  more  conventionally  structured  force.  This  entails 
addressing  these  poorly  understood  relationships. 

Training  Integration 

The  central  issue  in  training  integration  is  determining  the  training  requirements  for  an 
arbitrarily  defined  AFS.  Acquiring  the.se  data  .seems  straightforward.  The  training  curriculum  for 
an  arbitrary  AFS  structure  could  be  readily  determined  if  the  training  requirements  underpinning  a 
system  maintenance  task  were  tracked  during  system  development.  Curriculum  tracking  during 
system  development  is  currently  done  for  safety  or  for  "new”  technologies  through  the  current 
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LSAR  G  record.  Moreover,  a  complete  understanding,  on  somebody's  part,  ot  the  enure 
curriculum/iask  linking  during  the  acquisition  process  is  implicit  in  the  current  L.SA  process  in  that 
the  impact  of  a  new  design  is  required  by  the  current  LSAR.  Data  elements  exist  for  new  training 
and  personnel  skills  in  the  LSAR,  but  no  data  elements  exi.st  for  current  training  and  personnel 
skills  from  the  predecessor  system.  Information  about  the  status  quo  needs  to  be  available  at  some 
level  to  both  generate  and  validate  the  logistics  analyses  on  training  impact;  This  is  necessary 
because  the  status  quo  comprises  the  baseline  against  which  the  decision  of  whether  a  maintenance 
task  requires  new  training  or  personnel  skills  needs  to  be  made. 

Figure  6  presents  the  current  LS A/training  community  interface  and  its  proposed  revision. 
The  existing  interface  examines  the  required  maintenance  tasks  and  safety  program  requirements 
and  produces  requirements  for  safety  training.  It  also  identifies  where  new  technology  will  impac; 
the  training  of  the  baseline  AFS  maintenance  technicians.  The  revised  process  carries  the  baseline 
training  block  de.scriptions  and  develops  the  links  between  the  tasks  and  training  blocks  as  part  of 
the  baseline  data.  Reviewing  the  training-to-task  mapping  will  be  unnecessary  after  the  design  is 
specified  to  the  three-digit  WUC  level,  (late  in  concept  exploration)  because  fine  tuning  ot  the 
subsystem  components  will  not  affect  which  AFS  is  responsible  for  them. 
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Figure  6 

Proposed  LSA/Training  Integration 


The  current  Instructional  System  Development  (ISD)  process  produces  specific  target- 
behavioral  descriptions  for  each  training  block.  These  descriptions  should  readily  support 
matching  training  blocks  to  the  LSAR  C  record  task  descriptions  that  they  support.  .Additional 


effort  inherent  in  this  proposed  LSA  revision  is  in  maintaining  the  AFS-to-WUC  mapping,  mainly 
due  to  the  nomenclature  problem. 

An  estimate  of  the  impact  of  a  new  system  upon  the  training  curriculum  could  become 
available  quite  early  in  the  acquisition  process.  Moreover,  the  revised  behavioral  descriptions  arc 
then  available  to  the  detailed  task  analysis,  which  would  be  integrated  with  the  ISD  process  in  a 
fashion  to  be  specified — but  not  developed — during  the  Phase  II  effort.  The  LSA  process  is 
enhanced  by  having  an  explicit  training  baseline  against  which  system  de.sign  paniculars  might  be 
weighted.  The  ISD  process  is  enhanced  by  being  integrated  with  the  system  design  such  that  the 
impact  of  curriculum  retjuirements  becomes  available  in  time  to  influence  system  design  decisions. 

The  use  of  LSAR  in  ISD  has  been  repeatedly  suggested  in  the  past,  dating  back  to  the 
1970s  (for  example,  see  Staten  &  Boyle,  1988).  An  effon  currently  under  way,  the  Joint  Service 
ISDA-SAR  Decision  Support  System  (DSS)  (Sorensen  and  Park  1990),  is  developing  a  system  to 
supply  LSAR  data  (mainly  task  analysis  data)  to  develop  training  for  a  new  system.  The 
ISD/LSAR  DSS  picks  up  LSAR  data  at  the  point  where  task  analysis  is  complete  (generally  quite 
late  in  the  development  cycle)  and  makes  no  attempt  to  provide  early  a.s.sessment  of  the  impact  of 
technology  o.i  training  requirements  to  the  de.sign  activity.  Thus,  follow-ons  to  the  ISD/LSAR 
DSS  can  possibly  benefit  from  the  propo.sed  early  integration  of  LSA  and  ISD  engendered  in  this 
propo.sed  effon. 

Overall,  this  proposed  revision  develops  data  that  enhance  the  existing  LSA  and  ISD 
processes  while  providing  a  workable  means  to  assess  the  impact  of  AFS  structuring.  It  provides 
the  ability  to  determine  the  training  requirements  for  alternative  AFSs  in  a  quantitative  fashion. 
This  allows  AFS  restructuring  to  use  training  time  as  a  criterion  in  AFS  structure  optimization. 
Alternative  approaches  have  all  handled  this  problem  by  relying  on  expert  judges  to  rate  the 
similarity  of  existing  AFSs  or  maintenance  tasks.  This  proposal  represents  a  dramatic 
improvement  over  these  alternative  approaches  by  providing  a  measure  of  AFS  similarity  that  can 
be  continually  evaluated,  is  objective,  and  essentially  comes  as  an  added  benefit  of  an  LSAR  data 
expansion  that  has  a  great  deal  of  merit  in  its  own  right. 

Other  Training  Relationships 

The  previous  paragraphs  present  a  .scheme  to  develop  exact  training  rei]i:irements  for 
arbitrarily  defined  AFSs  to  support  AFS  restructuring,  but  whnt  ’c  known  about  the  poorly 
understood  relationships  between  training  requirements,  training  times,  and  aptitude  which  may 
moderate  these  requirements?  Beyond  information  about  the  existing  AFS  structure,  the 
relationship  among  aptitude,  training  times,  and  AFS  structure  is  little  understood.  This 
shortcoming  is  the  cost  of  the  personnel  and  training  management  strategy  that  the  Air  Force  has 
adopted.  Thus,  although  the  current  sy.stem  works,  and  can  probably  be  adjusted  to  work  again 
for  a  new  system  if  things  don’t  change  significantly,  the  effects  of  a  drastic  change  to  the  AFS 
structure  cannot  be  predicted.  The  question  is  "How  can  we  generalize  from  information  about  the 
current  AFS  structure  to  another  AFS  structure?"  If  we  view  the  current  AFSs  as  a  sample  from 
the  larger  population  of  possible  AFSs,  some  answers  might  be  forthcoming. 

Aptitude  Requirements  for  New  AFSs 

How  might  aptitude  requirements  for  drastically  consolidated  AFSs  be  estimated? 
Estimating  aptitude  for  new  AFSs  i.s  more  problematic  than  the  curriculum  issue.  Because  the  Air 
Force  personnel  process  doesn't  follow  the  accepted  empirical  predictor/criterion  prediction 
paradigm,  a  body  of  information  linking  aptitude  and  job  content  may  not  be  available.  Little  was 
uncovered  by  a  review  of  personnel  and  training  literature  on  this  issue.  For  example,  several 
studies  (for  example,  Mumford,  et  al.,  1987;  Newstad  &  Schuster,  1982)  tlevelop  an  empirical 
instrument  to  predict  aptitude  requirements  for  the  existing  Air  Force  initial  training  curriculum. 
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This  is  very  good  work,  but  it  deals  with  the  entire  training  curricula  and  is  not  generalizable  lo 
parts  or  composites  of  the  curricula  as  would  be  necesstu-y  in  an  analysis  tool  designed  to 
restructure  the  curriculum  for  an  alternative  AFS  structure. 

The  nature  of  the  relationship  between  aptitude  and  training  requirements  is  further 
confounded  by  the  relationship  between  training  time  and  aptitude.  If  time  is  unconstrained  tor  a 
fixed  curriculum,  the  single  most  difficult  block  of  material  would  detennine  the  minimal  aputude 
and  background  requirement  for  a  training  sequence.  If  training  time  is  held  constant  at  existing 
levels  for  each  training  block,  the  relationship  might  be  better  represented  by  an  additive  model, 
where  mastery  of  each  incremental  training  block  requires  a  bit  more  aptitude  or  background  than  a 
training  curriculum  not  containing  that  block. 

The  actual  situation  is  most  likely  a  mixture  of  the  power  and  additive  ellects:  a  broader 
AFS  structure  would  probably  be  best  manned  by  a  more  capable  population;  this  would  allow 
each  training  block  to  be  mastered  in  a  shorter  period.  On  the  other  hand,  career  training  times 
might  need  to  be  increased  to  accommodate  frequent  reviews  of  previously  mastered  concepts  as 
part  of  providing  students  with  the  substantially  larger  body  of  knowledge  required  to  pertorm  the 
duties  of  an  expanded  AFS. 

There  must  certainly  be  a  way  to  derive  credible  aptitude  estimates  tor  broadly  expanded 
AFSs  from  data  on  the  existing  AFS  structure  and  existing  AFS  aptitude  requirements.  Existing 
data  include  the  curriculum  blocks  for  existing  AFSs  and  their  minimal  aptitude  scores.  An 
examination  of  these  data  may  answer  whether  a  power  or  additive  model  is  appropriate  and 
provide  a  means  to  estimate  aptitude  requirements  for  arbitrarily  defined  AFSs. 

If  a  nonadditive  model  is  appropriate,  some  courses  common  to  several  AFSs  will 
determine  the  minimal  aptitude  scores  for  these  AFSs  while  other  common  courses  will  apparently 
have  no  influence.  Training  blocks  would  serve  as  a  partially  ordered  set  of  aptitude  requirement 
determiners.  This  relationship  among  training  blocks  could  be  used  to  remove  courses  from  the  .set 
of  independent  variables  within  a  regression  analysis  of  the  data.  The  problem  is  to  seek  out 
patterns  of  common  training  blocks  among  the  AFSs  and  a.ssemble  the  dominance  order  within  the 
data.  The  degree  to  which  the  nonadditive  model  is  appropriate  to  the  data  will  be  estimated  by  the 
degree  to  which  these  patterns  predict  the  data's  aptitude  requirements.  Situations  w-here  data  such 
as 


AFS  Training  Aptitude 
1;  1  2  X 

2;  1  Y 

will  be  identified:  where  X=Y.  a  dominance  relationship  exists;  otherw'i.se.  If  X>  Y,  training  block 
2  dominates  and  if  X<Y,  the  situation  is  indeterminate.  More  complex  relationships  such  as 

AFS  Training  Aptitude 

1;  I  2  3  X 

2:  I  2  Y 

indicate  joint  domination  of  Training  Block  3  by  Blocks  1  and  2  where  X=Y;  Training  block  3 
could  be  removed  from  the  analysis.  Alternatively,  in  situations  where  an  additive  model  is 
more  appropriate  to  the  situation.  Nondominant  courses  would  have  no  correlation  with  aptitude 
requirements.  The  existence  of  nondominant,  correlated  training  blocks  suggest.s  an  additive 
model.  A  regression  using  individual  training  blocks  as  dichotomous  predictor  variables  would 
have  significant  weights  on  only  the  dominant  variables,  as  these  are  the  only  ones  related  to  the 
criterion  (aptitude).  The  regression  model  would  appear  as 
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APTITUDE  =  B()  +  I31(conirnon  block  1)  +...+BN{common  block  N)  +... 

+B(N+r)(individual  block  l)+..+B(N+M)(individuai  block  M)  +  c. 

The  use  of  regression  to  estimate  weights  for  the  additive  model  has  two  obvious  Haws. 
First,  the  model  will  be  overfitted.  The  obvious  solution  is  to  reduce  the  number  of  predictors  to 
develop  the  predictor  equation.  This  approach  would  produce  a  simple  equation  which  might  well 
set  most  AFS  aptitude  scores  to  the  existing  mean.  The  second  problem  is  that  a  regression 
equation  would  have  little  meaning.  It  would  obviously  have  no  physical  meaning  in  cases  where 
a  training  block's  weight  is  negative.  It  is  difficult  to  imagine  a  situation  where  adding  a  panicular 
training  block  to  a  curriculum  has  the  effect  of  decreasing  the  average  aptitude  required  to  complete 
the  overall  curriculum.  Just  as  bad,  taking  all  the  training  courses  within  a  data  base  would  result 
in  an  aptitude  estiinaie  equal  to  the  mean  of  the  AFSs  contributing  to  the  data  base.  This  situation 
can  be  improved  upon.  Since  all  the  predictor  variables  are  dichotomous,  it  would  be  possible  to 
transform  the  equation  by  subtracting  the  value  of  the  most  negative  weight  from  both  sides  of  the 
equation.  This  would  provide  a  model  that  has  a  higher  degree  of  physical  meaning  in  that 
additional  courses  placed  into  a  curriculum  would  always  increase  the  aptitude  requirement.  This 
would  not  solve  the  overfitting  problem. 

The  approach  developed  in  the  Phase  II  effort  w'Ould  attack  the  ASVAB  requirements 
problem  through  separate  developments  of  a  regression  approach  and  a  nonlinear  predictor 
approach  employing  neural  networks. 

Other  Personnel  Issues 

The  "Training  times  vs.  Personnel  aptitudes  by  AFS”  trade-off  may  possibly  be  addres.sed 
through  training  records.  The  obvious  means  to  attain  an  estimate  of  this  trade-off  is  to  regress 
training  times  against  ASVAB  scores  for  a  suitably  representative  sample  of  training  courses.  It  is 
unclear  if  both  these  personnel-sensitive  items  are  available  at  one  location.  One  effort  reviewing 
this  same  problem  stated,  "The  level  of  aptitude  required  for  succe.ssful  performance  of  a  task  was 
found  to  be  conceptually  inseparable  from  the  time  required  to  learn  to  perform  the  task  at  a 
satisfactory  level"  (Bunch  et  al.,  1982).  While  the  present  author  considers  this  an  overstatement, 
this  analysis  would  consume  a  large  share  of  the  resources  available  to  the  present  effort.  Thus, 
training  time  will  not  be  a  variable  in  the  present  effort. 

Finally,  no  reference  to  a  study  that  attempted  to  correlate  AFS  attrition  level  with  specific 
task  requirements  was  found.  While  a  approach  similar  to  that  proposed  to  predict  ASV.AB 
requirements  could  be  applied  to  the  attrition  problem,  it  would  have  little  chance  of  being 
successful,  or  even  credible,  as  attrition  level  is  not  likely  to  be  clo.sely  related  to  specific  tasks 
within  an  AFS's  purview  to  the  same  extent  as  aptitude  is.  Moreover,  attrition  level  for  individual 
AFSs  vary  across  locations  and  time  to  an  extent  that  little  precision  is  gained  beyond  the  gross 
averages  when  using  these  data.  Thus,  we  will  use  specific  AFS  attrition  data  for  comparability 
purposes  and  force  averages  for  reconstituted  AFSs. 

Personnel  Management  Issues 

Analytical  support  for  maintenance  organization  analysis  and  career  path  structuring  will  be 
provided  in  this  effort.  The  trade-offs  surrounding  the.se  two  issues  are  even  cloudier  than  the 
"Poorly  Understood"  relation.ships  above  in  that  the  relevant  issues  cannot  be  neatly  laid  out.  But 
these  two  issues  are  as  vitally  related  to  the  feasibility  of  a  new  AFS  structure  as  are  its  training  or 
personnel  implications. 

Maintenance  organization  is  important.  The  principle  argument  put  forth  to  support  the 
development  of  more  general  AFSs  (i.e.,  that  more  broadly  responsible  AFSs  have  a  steadier 
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maintenance  task  demand  rate  and  can  be  utilized  more  fully)  applies  to  work  centers  as  well.  A 
larger  work  center  will  have  a  steadier  demand  rate  than  a  smaller  one  and  thus  be  able  to  more 
fully  utilize  its  maintenance  manpower.  The  trade-off  here  is  between  smaller,  more  specialized 
shops,  which  are  easier  to  manage,  and  larger  shops  which  reduce  overall  management  overhead 
but  become  more  complicated  to  manage  and  communicate  within. 

If  an  AFS  structure  is  to  succeed,  career  progression  must  be  taken  into  account  to  provide 
a  distribution  of  suitably  experienced  journeyman-level  maintainers  and  senior-level  supervisors  to 
man  the  maintenance  system.  The  structuring  of  work  centers  is  important  to  gaining  the 
experience  to  facilitate  this  career  progression.  Insofar  as  the  management  function  relies  on 
familiarity  with  the  tasks  performed  at  a  work  center  the  AFS  careers  leading  to  the  supervisory 
AFSs  should  be  exposed  to  these  work  centers.  Thus,  work  center  structuring  is  important  to 
developing  maintenance  efficiency  for  career  development. 

Maintenance  organization  analysis  and  career  path  structuring  seem  w-ell  worth  exploring  in 
the  present  effort,  and  is  a  relatively  untouched  arena  for  MPT  integration  and  automation. 
However,  since  the  basis  for  career  path  detemiination  and  work  center  structuring  are  unclear,  no 
optimization  strategy  is  apparent  at  this  time.  The  Phase  II  effon  wall  develop  a  m.eans  to  compute 
MPT  costs  for  plau.sible  options  in  these  areas  and  trust  the  analyst  to  provide  the  rationale  for  the 
changes. 


Implementation  Particulars 


Data  Ba.se  Design 

Figures  7  and  8  present  the  proposed  data  schema  for  the  effort.  Figure  7  contains  files 
that  are  primarily  designed  to  store  input  data  describing  the  aircraft,  mission,  and  maintenance 
particulars;  Figure  8  is  devoted  to  files  of  the  system’s  analysis  results.  Necessary  links  to  the 
LSAR,  equivalent  LSAR  Control  Numbers,  .stock  numbers,  etc.,  are  not  included  because  they  are 
not  necessary  parts  of  the  proposed  analysis  system  although  they  will  be  developed  as  part  of  the 
effort.  A  short  study  of  the  figures  will  complement  the  following  di.scussion.  Each  rectangle 
repre.sents  a  data  table,  with  its  name  at  the  top,  .separated  from  the  table  elements.  The  data  tables 
with  the  word  “join”  in  the  title  serve  to  associate  the  system’s  major  constructs,  but  are  of  little 
interest.  Table  elements  ending  in  “ID”  are  internal  identifiers  for  each  entity.  The  major  data 
constructs  are: 

maintenance  concepts 
AFSs 

work  centers  and  ba.ses 
missions  and  sorties 
aircraft 

systems  and  WUCs. 

A  maintenance  concept  is  a  collection  of  WUCs  each  joined  to  an  AFS,  a  work  center,  and 
a  description  of  the  task  in  'he  WORK_DESCRIPT  table.  One  data  base  can  store  several 
competing  maintenance  concepts  for  a  given  base,  aircraft,  and  mission  model.  The  task  class 
(TMAINT)  cla.ssifies  the  task  intoon-equipment,  off-equipment,  .scheduled,  unscheduled,  indirect, 
etc.,  types  of  maintenance.  The  additional  parameters  describing  the  task  tu"e  the  proportion  of  the 
time  this  AFS  performs  that  task  (PERC),  the  length  and  frequency  of  the  task  (LENGTH  and 
DEMAND)  and  the  average  and  maximum  crew  size  requirements. 

A  WUC  is  a  task.  It  is  given  a  name  (GNAME)  and  is  associated  with  training  and  with 
particular  subsystems  on  the  aircraft.  It  is  also  associated  with  a  description  in  the 
TA.‘^K_DESCR1P110NS  table.  These  are  essentially  the  LSAR  C  Record  task  descriptions. 
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An  AFS  is  an  Air  Force  job  within  a  career  field.  The  AFS  table  contains  the  AFS  name 
and  the  mechanical  and  electronics  ASVAB  minimum  scores.  An  AFS  is  associated  with  attrition 
and  skill-level  in  the  AFS_YEARLY  and  AFS_LEVEL  tables.  An  AFS  is  associated  with  its 
training  curriculum  and  task  assignments  through  the  TRAINING  (via  the 
TRAINING_AFS_JOIN  table)  and  the  WORK_DESCR]PT  tables. 

A  work  center  is  a  location  where  work  is  performed.  A  base  is  a  collection  of  work 
centers.  A  base  contains  several  parameters  relating  to  personnel  availability  and  operating  days 
per  year. 

A  sortie  is  defined  by  the  rate,  duration,  and  number  of  aircraft  involved  (BLOCK).  A 
mission  is  the  aggregation  of  sorties  flown  by  the  aircraft  in  the  model.  The  mission  provides  the 
impetus  for  maintenance  actions  in  defining  how  much  each  aircraft  type  in  the  model  is  used  and. 
hence,  the  maintenance  demand  for  its  constituent  systems.  Note  that  there  is  no  inherent 
constraint  to  the  number  of  different  aircraft  types  that  can  be  defined  in  the  model. 

An  aircraft  is  associated  with  a  name  and  a  primary  aircraft  authorization  (PAA)  in  the 
AIRCRAFT  table.  Aircraft  are  collections  of  systems.  A  system  corresponds  to  the  entities 
documented  on  individual  LSAR  B  records,  at  whatever  level  of  indenture  is  convenient,  but  is 
as.sociated  with  its  R&M  tasks  indirectly  through  WUCs.  This  follows  LSAR  logic  in  that  the 
R&M  data  are  on  the  C  and  D  records  rather  than  the  B  record.  Systems  can  also  be  associated 
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with  individual  sorties  to  model  sortie- specific  systems  or  handling,  and  with  work  centers  to 
model  support  equipment  maintenance  and  indirect  duties  associated  w'ith  w'ork  center  or  base 
support,  training,  and  management  tasks. 
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Figure  8 

Reports  Data  Schema. 


Figure  8  shows  the  structure  of  the  output  data,  although  .some  output  (e.g.,  a  new  AFS 
structure)  may  be  held  in  the  tables  from  Figure  7.  The  data  are  organized  by  analyses,  which  arc 
collections  of  individual  results.  An  analy.sis  is  reque.sted  by  an  ANALYSIS_j'ARAMS  table  entr\' 
which  defines  the  base,  mis.sion,  and  maintenance  concept  for  the  analysis.  The  various  results  are 
related  by  being  outcomes  from  analyses  produced  by  stepping  one  or  two  parameters  across  a 
range  of  their  parameters.  The  SYSTEM_MANPOWER_  RESULTS  table  contains  information  of 
interest  about  the  entire  scenario,  such  as  total  manpower  and  R&M  information.  The 
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AFS_MANPOWER_RESULTS  contain  information  about  the  workload  and  manning  for  a 
particular  AFS/work  center  combination.  The  S,  P,  U,  O,  and  D  prefixes  on  the  R&M  data  relate 
to  the  currently  defined  maintenance  types:  scheduled  off-equipment,  scheduled  on-equipment, 
unscheduled  on-equipment,  unscheduled  off-equipment,  and  duty  types. 

Data  Editing  Functions  and  User  Interface 

Data  editing  functions  and  user  interface  will  follow  the  model  developed  in  IMACAD. 
The  "data"  referred  to  in  the  description  of  user  function.s,  which  follows  this  paragraph,  consist  of 
the  WUC  designator,  descriptive  name,  alternative  designator,  time  to  failure  (TTF),  type  of  failure 
mechanism,  time  to  perform  ta.sk,  task  time  distribution,  task  type  (e.g.,  on-equipment,  back  shop, 
indirect,  inspection,  pre/post  flight,  etc.),  alternative  AFSs,  and  work  cetiter,  sortie,  or  aircraft  to 
which  the  task  relates.  These  tasks  can  be  associated  with  any  combination  of  work  center, 
aircraft,  sonie,  AFS,  or  LCOM  network.  Data  entry  and  editing  requirements  are: 

Enter  Data  at  N-level  WUC:  the  user  can  enter  data  at  any  level  of  detail. 

Edit  Data  at  N-level  WUC:  the  user  can  edit  any  data  element. 

Roll  data  up  from  N  to  N-m  level:  The  user  can  compress  data  to  a  lower  (i.e.,  fewer 
WUC  characters  or  more  general )  level  of  detail. 

View  N-level  WUC  at  N-m  level:  The  u.ser  can  view  data  at  their  native  level  or  any  lower 
level  of  detail. 

Edit  N-level  WUC  data  at  N-m  level:  The  user  can  edit  data  at  the  level  he  views  them; 
changes  are  transferred  to  underlying  data. 

Batch  edit;  The  user  can  select  any  set  of  tasks  to  edit  (i.e.,  multiply  by  a  con.siant.  .set  to  a 
constant,  add  a  constant ). 

Expand  Data  from  N  to  N-(-l  level  detail:  The  user  is  led  through  a  dialogue  to  expand  data 
from  a  task  at  any  level  to  the  layer  immediately  beneath  that  level. 

Merge  range  of  data  from  data  bank:  The  user  can  perfomi  merges/replacements  of  any 
size  from  other  aircraft/base/sortie/AFS  task  collections. 

Data  Anaivsis/Presentation  Functions 

The  ability  to  generate  an  R&M  report  for  any  combination  of  work  center,  aircraft, 
mission,  AFS,  or  associated  tasks  will  be  provided.  Summary  statistics  will  include  TIT. 
MMH/FH  and/or  sortie,  and  average  maintenance  times  (time  to  repair  (TTR))  by  maintenance 
type,  average  crew  size,  and  composition.  These  repons  will  help  validate  the  data  of  an  emerging 
system  and  could  also  be  used  for  early  R&M  analysis  in  system  development. 

The  proposed  system  will  adapt  the  analytic  manpower  analysis  strategy  first  developed  in 
IMACAD  (Miller  &  Boyle,  in  press)  and  expanded  upon  in  the  TDSTL  11  effort.  Thus,  the  R&M 
reports  will  include  manpower-by-AFS  statistics  along  with  the  customary  task  times  and 
frequency  data.  The  addition  of  the  training  data  will  necessitate  additional  reporting,  authoring, 
and  editing  facilities  to  allow  the  training  courses  and  associated  behavioral  objectives  to  be 
arranged  by  task,  AFS,  work  center,  WUC,  or  aircraft  type  and  printed  or  displayed  for  the  user. 
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Reporting;  Functions 


The  fixed  steps  of  systems  engineering  and  the  Weapon  Systeifi  Acquisition  Process,  along 
with  the  unavoidable  serial  nature  of  the  analysis  process  and  the  tendency  for  bureaucracies  to 
specialize  and  compartmentalize  responsibilities,  have  produced  a  disjointed  logistics  analysis 
community.  The  extreme  example  is,  of  course,  the  ISD/L,SA  schism,  but  other  examples  abound. 

One  symptom  of  the  lack  of  communication  within  the  logistics  community  is  that 
successive  steps  of  the  process  tend  to  treat  their  input  data — that  is,  the  data  provided  them  by 
previous  steps  within  the  chain  of  analysis — as  fixed  quantities  rather  than  ranges  or  potential 
trade-olf  relationships. 

The  R&M/manpower  connection  is  of  interest  in  this  regard.  The  manpower  analy  si 
rightfully  assumes  the  mission  essential  reliability  requirements  to  be  fixed,  then  adopts  the 
comparability  baseline  system  to  meet  the  sortie  and  R&M  parameters  specified  in  the  retjuircmenis 
documentation.  A  manpowci  estimate  is  sub.sequently  produced.  This  number  does  nerhing  to 
inform  R&M,  equipment  design,  maintenance  planning,  or  any  other  portion  of  the  logistics 
system  beyond  the  training  and  personnel  communities,  as  outlined  above.  Moreover,  potential 
trade-offs— such  as  the  relationship  among  manpower,  AFS  structure,  and  maintenance  concept 
and  organization — are  not  addressed. 

The  lack  of  subsequent  communication  between  the  engineering  and  manpowi.*r 
communities  is  worth  examining.  Feedback  from  manpower  to  R&M  management  and  planning 
should  permit  the  ready  assessment  of  changes  to  manpower  requirements  from  a  change  in  either 
the  reliability  or  maintenance  time  or  crncept  (e.g.,  a  change  from  on-base  to  off-base  repair  for  an 
item).  .As  discussed  above,  the  trade-off  beiweet:  task  frequency  and  task  length  is  not  as 
predictable  for  manpower-by-AFS  as  it  is  for  MMH/FFF  A  hypothetical  relationship  between 
frequency  and  time  for  manpower  is  presented  in  Figure  9.  The  isobars  are  the  lines  on  the  R&M 
curves  relative  to  the  baseline  where  manpower  levels  are  the  same.  I'he  graph  is  not  imended  to 
represent  a  known  relationship,  but  should  be  interpreted  as  indicating  that  increases  in 
maintenance  times  would  be  less  deleterious  to  manpower  than  would  decreases  in  reliability. 
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Figure  9 

R&M  Manpower  Trade -off  Curves 


The  present  effort  proposes  to  generate  trade-off  inforniation  of  this  son  with  tiianpouer 
estimates  for  use  in  R&M  management.  This  should  support  the  R&M  .nanagcmcnt  process  in  the 
same  fashion  as  does  the  main'^enance-manpower-per-flight-hoiir  centered  approach,  but  allow 
direct  management  of  maintenance  slots  and  (with  the  addition  of  training,  personnel,  and  cost 
models)  MPT  costs.  Parameters  available  for  trade-off  analysis  of  this  type  include  R&M  (times 
and  crew  size)  parameters  by  maintenance  type,  sortie  nee  and  length,  and  PAA. 

The  benefits  of  AFS  restructuring  can  also  be  approximated  numerically.  Figure  10 
presents  results  from  a  hypothetical  analysis  of  AFS  restructuring  within  a  single  work  center,  d'he 
ba.se]ine  condition  (15  AFSs)  requires  58  persons.  The  manpower  estimate  for  14  AFSs  would  be 
derived  by  removing  an  AFS,  reapportioning  its  workload  to  the  remaining  AFSs.  and 
recomputing  manpower  with  the  resultant  AFS  structure.  By  repeating  this  process  using  several 
different  AFSs,  a  stable  estimate  of  the  resultant  manpower  requirement  would  result.  The  process 
would  be  repeated  for  the  other  AFS  levels,  resulting  in  a  numerical  estimate  of  the  value  of 
compressing  AFSs  for  a  given  maintenance  scenario. 

Automating  the  procedure  to  select  the  AFSs  that  will  produce  the  maximum  return  for  ,AFS 
combination  would  consist  of  removing  the  AFS  with  the  lowest  utilization  for  decomposition  or 
.selecting  the  two  with  lowest  utilization  for  consolidation  into  a  single  AFS.  Computationally,  it 
would  be  easier  to  compute  the  effects  of  combining  two  AFSs  than  to  decompose  an  AFS  and 
distribute  its  workload  to  other  AFSs  as,  in  the  former  case,  manpower  would  only  need  to  be 
computed  for  the  new  AFS,  not  the  entire  work  center. 


WORK  CENTER  “A  SHOP* 


Number  of  AFSs 


Figure  10 

Numerical  Prediction  of  AFS  Restructuring  Effects 

An  "optimal”  AFS  structure  could  be  developed  by  clustering  tasks  according  to  their 
degree  of  training  overlap  as  follows: 

1 )  Select  a  maximum  number  of  AFSs  with  which  to  populate  the  new  AFS  Structure. 

2)  Compute  a  measure  of  similarity  between  all  task  pairs  from  the  amount  of 
noncommon  training  they  possess.  This  relationship  is  not  necessarily  symmetrical 
(e.g.,  if  task  A’s  training  is  a  proper  sub.set  of  task  B’s  training,  but  there  are  two 
weeks  of  training  within  B,  not  in  A.  the  distance  from  A  to  B  is  (i.  w  lvle  the  distance 
from  B  to  A  is  two  weeks). 
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3)  Moving  t'roni  ihc  siiKillest  to  the  largest  distances,  clusici  utsks  according  lo  ihcn 
maximum  distance  (using  the  lesser  distance  as  a  ne-hrcak.  il  needed),  kecompuie  the 
training  requirements  tor  die  resultant  cluster  after  each  combination,  l  liis  uii! 
assemble  all  of  the  tasks  that  require  less  training  under  ilu>se  that  retjuire  tiie  most 
training  (i.e..  group  together  tasks  that  require  subsets  ot  the  most  complex  task  s 
uainiiig  requirements. 

4)  Stopping  the  process  prior  to  developing  the  solution  containing  just  one  big  AbS 
will  be  developed  as  part  of  the  proposed  effort,  but  the  following  are  possible:  a) 
fixed  number  of  .AFSs;  b)  manpower  falls  below  some  arbitrariK  set  Innit.  C) 
utili;tafioft  reaches  .some  predefined  limit;  d>  total  training  length  (i.c,,  1,  (number  in 
.AFS  "  training  length))  is  minimized;  e)  total  numbers  ti.e..  Total  Maintainers  ->' 
.Annual  Attritions  training  days/365)  of  individuals  is  minimized;  fi  ,\.SV,AF< 
requirements  of  the  maintenance  cadre  reaches  .some  predeiennined  limit;  g  i  MF 1  cost 
is  minimized  (via  a  combination  of  the  issues  addressed  in  e)  and  f)  plus  a  cost  model ) 

.Note  also  that  the  stopping  rules  need  to  be  applied  to  the  entire  .ATS  structure.  .Attempting 
to  optimize  some  .AFSs  result  in  other  AT-Ss  prossibly  being  subopiimal.  thereby  nulliibing  tiic 
manpower  or  cost  gains  made  by  the  panial  optimization  on  the  consiiieretl  AF'Ss. 

It  would  he  possible  to  levy  additional  constraints  or  goals  on  the  optimal  task  clustering 
problem,  such  as  fitting  training  length  or  .ASV.AB  requirements  to  a  fixed  distribution,  rather  than 
imposing  a  limit  to  the  total.  It  wDitld  also  be  possible  to  redefine  the  interttisk  dtsiaticcs  as 
additirxia!  ASV.AB  re(.|uirement.s  for  tlie  combined  tasks.  It  is  unclear  whether  this  will  he 
ixmeficial. 

Implementation  Fnvironment 

The  proposed  system  will  be  developed  on  an  MS-DOS  platform  in  Microsoft  Windows. 
The  programming  language  will  be  C++  using  the  Borland  Paradox  relational  data  base  manager. 

Relationshin  to  L.oaistics  Support  Analysis  Record 

One  goal  of  this  effort  is  to  produce  a  Cla.ss  2  MIL-S'TD  1.3X8-2B  LSAR  data  automation 
system.  That  is.  the  system  data  will  be  mapped  to  their  LSAR  counterpart  where  possible,  and 
the  system  will  produce  reports  in  LS.AR  format.  However,  .some  data  will  he  externa!  to  LS.AR 
and  some  will  fse  in  a  different  formal.  Fore.xampJe,  LSAR  handles  la.sk  times  by  asking  for  (a)  an 
average  task  time,  (b)  a  maximum  task  time,  and  (c)  the  percentage  of  tasks  that  will  exceed  the 
maximum  task  time.  This  confusing  scheme  will  not  be  adopted;  we  will  carry  this  data  as  a 
distribution,  a  mean,  and  a  variance  measure. 

V,  WORK  PLAN 

The  Pha.se  11  work  plan  describes  the  details  of  the  proposed  individual  tasks,  to  develop 
the  system  described  in  Section  IV,  The  effort  will  develop  and  validate  a  methodology  for 
R&.M/MPT  and  AFS  structure  optimization  within  a  single  weapon  system.  The  resultant  system 
will  provide  the  means  to  generate  R&M/manpower  trade-off  information  allowing  direct 
management  ot  maintenance  slots  and  MPT  costs,  instead  of  holding  these  parameters  as 
constraints,  as  is  currently  the  practice.  The  output  of  this  system  will  provide  several  criteria  to 
estimate  the  improvement  offered  by  alternative  maintenance/AF\S/operational  structures  including  a 
variety  of  co.st  breakdowns,  total  manpower,  training  load,  personnel  flow'  rates,  and  operational 
some  rate  at  fixed  manpower. 
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Months  after 
Contract  (MAC) : 


Contract  Start 
Incremental  Funding 
Kick-Off  Meeting 
SYSTEM  REQ  MEHTS 

Requirements  Analysis 
Early  Reliability  Analysis 
Alternatives  Analysis 
Level  of  Repair  Analysis 
Maintenance  Concept 
Training  Requirements 
Training  Costs 
Personnel  Modeling 
Personnel  Costs 
Other  (e  g.,  facilities) 

DATA  COLLECTION 
Three  Digit  VUCs 
F-16  Training  Rqmts 
Training  Times  &.  Costs 
Task/Training  Correlation 
Personnel  Reqmts  &  Costs 
Career  &  Attrition 
Informal  Tech  Data  CDRL 
SOFTVARE  DEVELOPMENT 
LSAR/ISD  Familiarization 
Data  Base  Design 
Interface  Design 
System  Design 
Incremental  Develop  &  Test 
Develop  User  Manuals 
System  Documentation 
Software  Design  Spec 
Softvare  Delivery 
SYSTEM  EVALUATION 
Validation 
Documentation 
Close  Out  Meeting 
Final  Report 
Contract  End 
Monthly  Status  Report 
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Figure  1 ) 

Proposed  Phase  II  Schedule 


The  effort  is  divided  into  four  activities;  system  reijuiremeiits  specification,  data  collection, 
software  development,  and  system  evaluation.  The  effon  builds  upon  previous  UTS  corporate  and 
team  member  e.xperience  in  automating  integrated  logistics  support  analysis  tools.  The  schedule  of 
tasks  and  milestones  is  presented  in  Figure  1 1. 

System  Requirements  Specification 

Analytic  data  manipulation,  data  retjuirements,  and  user  inti^rfaces  will  be  cor'pletely 
specified  dunng  this  activity,  using  the  facility  described  in  Section  IV  as  a  baseline  for  the.w 
developments.  Since  data  to  support  the  analyses  is  important  to  both  the  success  of  the  Phase  11 
program  and  subsequent  u.sers  of  the  .sysiem.  we  will  also  use  the  requirements  specification 
development  to  plan  data  collection.  The  third  important  job  during  this  period  will  he  m 
documenting  the  link  between  the  LSAR  data  structure  and  the  proposed  analytic  framework  for 
use  in  software  development.' 

R&M/MPT  Analyses  Supponed 

The  requirements  analysis  for  the  proposed  eP'ort  will  consist  of  first  developing  a  detailed 
presentation  of  our  analysis,  data,  and  user  interface  requirements  The  UES  project  team  will 
present  these  concepts  to  government  experts  in  the  various  logistics  tireas  and  incorporate  their 
feedback.  These  experts  will  be  identified  through  personal  contacts  of  the  UES  team  members 
and  government  sponsors,  and  will  mainly  be  WPAFB  personnel.  The  program  review  at  the  end 
of  this  activity  will  present  the  detailed  design  to  project  monitors  for  approval.  LTrS  will  identity 
and  interview  specialists  in  the  following  areas: 

Requirements  analysis  regarding  logistics  is  the  initial  determination  of  minimal  critical 
system  reliability  and  maximum  inter-sortie  maintenance  times  for  competing  system  concepts. 
The  usual  means  of  handling  reliability  and  maintainability  in  this  analysis  is  to  first  determine  the 
requisite  availability  for  the  aircraft  if  it  is  to  meet  the  operational  requirement.  This  high  level 
analysis  trades  PAA  against  the  system  R&M  profile  (expressed  as  availability)  to  minimize 
expected  system  cost  against  the  mission  .scenarios.  Availability  determines  the  critical  system 
reliability  and  maximum  allowable  maintenance  man-hours  per  flight  hour.  This,  along  w  ith  PA.\. 
permits  an  approximate  manpower  estimate  to  be  developed.  The  critical  question  is  how  early  a 
comparison-based  manpower  analysis  will  be  useful  in  providing  manpower  estimates  from  a 
closer  view  of  the  maintenance  environment  than  is  currently  possible. 

Early  reliability  and  maintainability  analysis  breaks  down  the  weapon  system’s  R&.\1 
constraints  into  requirements  for  particular  systems,  as  per  the  system  engineering  model.  These 
requirements  are  successively  refined  and  fed  back  to  the  design  activity  until  the  maintenance 
concept  is  formed.  The  propo.sed  system  will  support  the  evolution  of  the  R&M  and  maintenance 
concept  data  through  this  process,  including  facilities  to  analyze  and  report  on  the  subsystems 
definition  and  design  at  any  level  of  detail  available.  The  major  addition  to  the  current  R&M 
proce.ss  is  the  reporting  of  e.stimated  manpower  by  AFS  in  addition  to  the  maintenance  manpower 
per  night  hour  statistic. 

Alternatives  anaivsi.s  is  the  estimarion  of  the  relative  burdens  of  alternative  system  and 
subsystem  choices.  The  proposed  tool  will  support  this  analysis  by  facilitating  the  side-to-side 
development  and  analysis  of  alternative  models  of  the  emerging  .system.  The  proposed  system  w  ill 
be  prescriptive  in  allowing  the  analyst  to  easily  perform  excursions  upon  the  systems'  major 
parameters  to  determine  where  opportunities  exist  for  savings  in  MPT  areas. 

l.evel  of  repair  analysis  is  an  examination  of  the  trade-off  among  reliability,  repair  strategy, 
manpower,  spares  cost,  and  support  equipment  requirements  to  achieve  a  given  level  of  system 
availability.  The  proposed  system  will  support  this  analysis  through  providing  MPT  costs  for  the 


various  support  alternatives  and  allowing  the  analyst  to  combine  and  comptire  these  costs  with  'he 
less  equivocal  spares  and  support  equipment  costs.  The  requirements  analysis  lor  the  present 
effort  will  examine  the  data  requirements  needed  to  allow  trades  against  support  cquipriient 
maintenance,  spare  levels  to  meet  a  given  demand  level,  and  depot  maintenance  costs. 

Maintenance  concept  determination  examines  the  association  among  work  centers,  level  ol 
repair,  support  equipment,  and  assigned  AFSs.  Since  the  work  center  is  the  arena  where 
maintenance  concept  is  explored,  the  proposed  system  relies  heavily  on  work  center  attributes  in 
building  and  evaluating  base-level  maintenance  manpower.  Consideration  of  issues  such  as  shift 
policy,  requisite  supervision,  allocation  of  indirect  labor  and  duties  w'ili  provide  a  unique  analysis 
capability  in  this  arena.  Supponing  maintenance  concept  analysis  consists  of  providing  the  analyst 
the  ability  to  develop  and  compare  alternative  work  centers  implementing  the  competing 
maintenance  concepts.  The  major  analysis  issue  in  both  this  area  and  in  the  previous  one  is  in 
developing  accurate  cost  data  against  which  to  compare  the  MPT  data  generated  from  the  proposed 
system.  The  data  issue  in  supporting  this  analysis  is  the  availability  and  format  of  data  that  usually 
flow  s  from  reliability-centered  maintenance  and  level  of  repair  analysis;  if  it  cannot  be  assumed  to 
exist  w'ithin  the  LSAR  structure. 

Training  requirements  determination  is  the  process  of  predicting  AFS-specific  and  total 
force  training  requirements  and  the  resulting  burden  upon  the  training  system.  Ifhis  is  currently 
performed  by  identifying  changes  to  the  predecessor  system  requirements;  the  proposed  effort  w  ill 
replace  this  by  developing  data  about  the  emerging  system's  total  training  profile.  Early  in  the 
development  process,  this  analysis  will  be  comparison-based.  Once  the  training/task  correlation 
becomes  available,  the  analysis  will  include  determining  localized  impact  of  the  nevv  system  on  the 
training  system  through  an  exact  determination  of  the  training  requirements  for  the  proposed 
design.  The  critical  analysis  issue  is  the  impact  of  the  emerging  system's  training  requirements  on 
the  baseline  training  requirements.  The  onus  of  developing  training/task  data  for  common  use  of 
this  tool  is  one  critical  data  issue.  The  type  of  data  necessary  to  allow  consideration  of  training 
delivery  alternatives  within  the  analysis  is  another  critical  data  issue.  The  point  at  which  the  data 
are  firm  enough  to  allow  analyses  to  analyze  alternatives  such  as  clo.sed  looping  and  AFS 
restructuring  is  the  final  critical  data  issue. 

Training  costs  are  the  costs  associated  with  delivering,  modifying,  and  developing  the 
training  received  by  the  emerging  system's  maintenance  cadre.  The  training  concept  for  a  given 
training  block  drives  the  data  requirements  and  sources;  a  classroom  course's  costs  entail  a 
development  cost  and  a  per-student  cost  for  lodging,  instructor,  facilities,  materials,  etc.,  while  a 
self-study  course  entails  only  a  development  cost  and  the  trainees'  time.  OJT  is  somewhere 
between  these  two  extremes.  The  critical  analysis  issue  is  determining  when  the  emerging 
system's  data  has  become  firm  enough  to  afford  stable  estimates  of  the  new  system's  training 
burden.  The  critical  data  issue  is  how  to  develop  prescriptive,  design-relevant  feedback  to  exploit 
the  training  cost  statistics  we  are  developing. 

Personnel  modeling  is  the  determination  of  Air  Force  career  paths,  the  projection  of 
potential  candidates'  necessary  attributes,  and  the  projection  of  future  recruiting  reciirements.  The 
proposed  system  will  provide  a  projection  of  the  emerging  system's  force  requirenients  to  support 
the  base  level  operation  modeled,  including  numbers  of  personnel  required  per  year  of  service  and 
level.  Resolving  these  data  with  force-wide  concerns  is  the  major  analysis  issue  in  this  portion  of 
the  requirements  determination  for  the  proposed  system.  The  correlation  between  the  propc;sed 
system's  data  requirements  and  those  available  through  specialists  in  force  level  personnel 
modelers  and  the  availability  of  these  data — the  critical  data  issues — will  also  be  determined  in  this 
activity. 

Personnel  costs  include  salary  and  support  costs,  recruiting  costs,  training  costs, 
reenlisiment  bonuses,  etc.  The  important  analysis  issue  is  in  developing  a  suitably  detailed  cost 


35 


model  without  getting  over  complicated.  The  baseline  data  consist  of  an  average  cost  b>  year  oi 
service.  The  exact  determination  of  what  this  staii.stic  needs  to  include  is  the  major  data  issue  ot 
this  portion  of  the  effort. 

Other  features  of  the  model  are  base  level  issues  such  as  facilities  and  security 
requirements.  The  base  fixed  costs  can  be  ignored  within  the  conte.xt  of  the  proposed  system 
beyond  the  level  of  detail  laid  out  in  the  LSAR  requirements,  but  the  costs  that  are  variable  and 
associated  with  manpower  levels  need  to  be  identified  and  included  in  the  system  development. 


Requirements  Development  Strategy 

We  will  refine  our  requirements  by  interview.  Our  strategy  is  to  identify  experts  and  which 
of  the  R&M/MPT  function  presented  in  the  preceding  paragraphs  they  siippon,  give  them  a  general 
presentation  of  our  goals  and  approach.  We  will  then  solicit  their  comments  as  we  step  them 
through  our  model  of  their  process,  and  our  interface  concepts.  .At  least  two  individuals 
representing  each  R&M/MPT  function  will  be  contacted.  The  team  programmer/tinalysi  will 
manage  the  requirements  documentation  since  the  requirements  will  eventually  serve  as  the 
software  design  guidance. 

Requirements  Reponing 

An  informal  technical  data  deliverable  will  be  prepared  and  delivered  four  months  after- 
contract  award  documenting  the  results  of  the  system  requirements  analysis.  This  deliverable  w  ill 
also  include  the  data  sources  for  all  of  the  data  identified  as  part  of  the  requirements  analysis.  The 
impact  of  data  shortfalls  and  workarounds  will  be  provided  as  part  of  this  deliverable.  This 
information  will  also  be  pre.sented  during  a  review  of  the  project  to  be  held  at  the  four-month 
Juncture. 


Data  Collection 


The  testbed  for  the  proposed  effort  will  be  the  F-16  C&D  wing  at  Shaw-  .AFB,  South 
Carolina.  Operational  and  maintenance  data  will  come  from  a  combination  of  Maintenance  and 
Operational  Data  Access  System  (MODAS),  LCOM,  and  personal  interviews.  There  are  numerous 
sources  of  MPT  data;  the  exact  source(s)  of  each  datum  required  for  the  effort  will  be  presented  as 
part  of  the  requirements  analysis  effort's  reporting  efforts. 

Other  than  the  operational  information,  data  requirements  of  the  proposed  effort  are  aj 
complete  workload  by  AFS  by  work  center  data  at  the  three-digit  WUC,  with  additional  detail 
where  required  to  differentiate  the  domains  of  AFSs  working  under  the  same  three-digit  W'UC;  b) 
formal,  follow-on,  and  OJT  training  requirements  for  each  F-16  AFS;  c)  training  costs  for  this 
training;  d)  associations  between  the  training  and  the  tasks;  e)  Mechanical  and  Electrical  ASVAB 
subscale  requirements  for  each  F-16  AFS;  0  career  progression  and  attrition  rates  for  each  F-16 
AFS  and  the  personnel  costs  for  recruiting  and  by  year  costs;  and  g)  recruiting  costs  by  ASVAB 
category. 

Data  Collection  Strategy 

The  proposed  effort  will  identify  data  sources  as  part  of  the  system  requirement 
determination  process,  and  actually  begin  to  collect  this  data  as  soon  as  arrangements  for  such  can 
be  made.  This  data  will  be  assembled  in  the  relational  data  base  manager  shell,  the  initial  draft  of 
which  shall  be  put  together  during  the  requirements  phase.  Multiple  sources  of  data  will  be 
consulted  where  possible,  with  data  definitions  and  consolidation  strategies  from  the  diverse 
sources  documented  during  the  requirements  detemiination  activity. 
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Data  Preparation 

Associations  between  training  blocks  and  task  elements  will  be  developed  during  this  phase 
of  the  effort.  In  an  ideal  world,  a  level  of  task  and  training  aggregation  would  exist  where  tasks 
would  all  be  uniquely  associated  with  day-sized  chunks  of  training.  .As  this  is  not  the  ease,  the 
task/training  association  activity  will  initially  be  restricted  to  one  or  two  sysieius  w  hich  are  know  it 
to  fall  w'ithin  the  domain  of  a  single  AFS,  such  as,  for  instance,  amtaments  or  weapons.  Some  of 
the  training — theory  of  operation,  for  instance — will  cover  large  numbers  of  tasks  and  be 
indivisible,  and  easy  to  analyze.  Other  training  may  require  we  dig  down  below'  the  three  digit 
WUC  task  to  get  a  pure  match  between  training  and  duties.  The  prospect  that  this  class  of  data 
cannot  be  reliably  developed  is  the  largest  technical  risk  in  the  effon. 

Data  Reporting 

An  informal  technical  data  deliverable  at  9  months  after  contract  award  will  document  the 
data  collection  activity  and  present  raw  and  summarized  views  of  the  data.  Additionally,  the 
baseline  conditions  that  the  data  are  intended  to  reproduce  will  be  specified.  I'he  validation  plan 
outlining  these  conditions  w'ill  be  presented  at  this  time.  Standard  approaches  to  performing  the 
functions  of  the  proposed  system  will  also  be  listed  and  provide  a  basis  for  the  user  evaluation  of 
the  system  during  the  evaluation  pha.se  of  the  effort. 

Software  Development 

The  system  will  be  implemented  on  a  66  MHz  80486DX  personal  computer  in  the 
Windows  environment,  using  C+4-  and  the  Paradox  relational  data  base  kernel  and  librar)'.  I'his 
approximates  the  standard  personal  computer  in  use  during  the  last  half  of  this  decade,  and  should 
provide  reasonable  performance  with  the  proposed  .system;  i.e.,  single  workcenter  analyses  in 
.seconds;  single  base  model  runs  in  2-5  minutes;  and  runs  with  25  to  100  excursions  in  one  or  two 
hours.  A  de,scription  of  the  hardware  and  software  is  included  in  the  cost  proposal. 

The  baseline  version  of  the  proposed  system  was  described  in  Section  IV,  This 
de,scription,  recast  more  formally  as  the  system  requirements  document  and  refined  during  the 
requirements  analysis  and  data  collection  activities,  will  be  the  focus  of  the  software  design 
activity.  Specifics  of  the  software  development  are  described  in  the  following  paragraphs. 

Finalization  of  Data  Dictionary 

Final  data  base  specification  will  expand  the  baseline  data  table  definitions  pre.sented  in 
Section  IV  to  the  requirements  identified  in  the  requirement  determination  and  LSAR  familiarization 
tasks.  At  the  point  in  the  program  when  software  coding  will  take  place,  the  data  tables  will  have 
served  as  the  basis  for  requirements  definition  and  data  collection,  and  contain  the  results  of  the 
data  collection  effort.  If  necessary,  table  definitions  will  be  altered  based  upon  that  experience  or 
anticipated  problems  in  the  sub.sequent  software  development  steps.  The  internal  variable  labels  to 
be  us  d  in  the  system  will  also  be  finalized. 

LSAR/ISD  familiarization  will  be  a  low  level  activity  at  the  beginning  of  the  proposed  effort 
to  acquaint  team  personnel  with  the  new  MIL-STD-1388-2B  standard  and  to  flesh  out  the  proposed 
data  model  for  requirements  determination  and  data  collection.  Part  of  this  will  entail  developing  a 
cross-reference  between  the  proposed  system's  data  definition  and  the  LSAR  items  they  represent. 
The  data  related  to  training,  personnel,  and,  particularly,  costs  are  not  all  included  in  the  previous 
LSAR  definition.  Differences  between  the  proposed  system  and  LSAR  data  describing 
substantially  the  same  thing  generally  concern  dimensions;  e.g.,  the  baseline  data  definition  for  the 
proposed  system  deals  in  months  as  the  reporting  unit,  whereas  LSAR  usually  prefers  per  year 
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numbers.  The  preferred  rectification  for  these  cases  is  to  adjust  the  proposed  system  to  the  LSAK 
requirement. 

One  tie-in  to  a  Phase  III  effort  will  be  developed  as  a  byproduct  of  the  crosslisting  ol 
LSAR  definitions.  A  strategy  to  expand  the  propo.sed  .system  to  an  L.SAR  class  2  automation 
system  through  expanding  the  data  base  definition  to  the  entire  LSAR  definition  to  be  developetl  as 
part  of  the  final  repon  will  be  ba.sed  on  this  activity. 

Interface  Specification  and  Considerations 

Interface  design  will  expand  upon  the  baseline  interface  facilities  de.scribed  in  Section  ?< 
during  the  requirements  determination  process.  Screen  layouts  for  the  various  functions  will  be 
proposed  and  evaluated  as  part  of  the  requirements.  Previous  experience  on  the  I.MAC.XD  and 
TDSTL  efforts  have  taught  that  the  major  problem  will  be  to  present  appropriate  information  to 
perfomi  a  wider  variety  of  data  entry  and  edition  jobs  than  might  at  first  seem  neces.sary.  .As  a 
particular  purpose  will  often  have  use  for  information  from  several  tables,  the  screen  that  tries  to 
handle  too  wide  a  variety  of  purpo.ses  can  rapidly  fill  with  information  that  is  not  of  interest  to  all 
purposes,  resulting  in  confusing  dialogues  or  necessitating  a  plethora  of  separate,  single  purpose 
displays.  A  second,  related  problem  was  in  helping  the  user  move  among  dialogues;  it  often  was 
necessary  to  add  navigation  shortcuts  to  individual  dialogues  to  allou'  a  user  to  movc  among 
several  dialogues  in  the  IMACAD/TDSTL  application.  Ultimately,  this  solution  will  lead  to  a 
having  everything  connected  to  everything  else,  which  can  al.so  be  confusing. 

To  surmount  the.se  human-interface  problems  two  strategies  will  be  adopted.  First,  the 
propo.sed  effon  will  develop  flow  diagrams  of  user  interactions  across  the  data  definition  as  part  ot 
the  requirements  analysis.  These  will  be  verified  during  the  requirements  interviews  and  compared 
against  the  proposed  user  interfaces  to  determine  data  requirements  and  navigation  strategies. 
Second,  the  user  interface  will  be  developed  using  resizable  windows  to  display  infomiation  to  the 
u.ser.  Standtu'd  dialogues  will  then  be  defined  which  configure  the  general  dialogues  to  support 
particular  purposes.  Additionally,  the  user  will  be  able  to  customize  his  own  views  to  support  his 
particular  needs.  For  example,  if  a  user  is  looking  at  the  maintenance  concept  (task  descriptions, 
systems,  and  .AFSs  for  a  particular  work  center)  and  wishes  to  compare  two  work  centers,  he 
could  resize  his  initial  display  w'indow  to  fit  another  work  center’s  data  onto  the  screen  ;is  well. 
The  goal  is  to  make  the  interface  a  fiexible  as  possible  without  completely  turning  the  effort  into  an 
interface  development  project. 

Final  Design 

The  final  government-approved  version  of  the  system  requirements  will  consist  of  a 
detailed  description  of  the  data  processing  requirements,  the  final  data  base  schematic  and  data 
dictionary,  and  annotated  pictures  of  the  interfaces.  This  information  will  be  the  foundation  for 
software  coding  and  verification  and  for  subsequent  system  documentation.  This  material  will  be 
internally  reviewed  by  senior-level  UES  team  members  prior  to  coding,  who  will  also  aid  the 
principal  inve.stigator  and  programmer  in  developing  an  activity  checklist  covering  software  coding 
and  verification.  A  sample  data  .set  incorporating  all  of  the  system's  data  features  will  be  developed 
and  solved  manually  for  the  purpose  of  development  testing. 
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Incremental  coding  and  test  of  the  software  will  proceed  nine  months  after  contract  award, 
for  a  period  of  seven  months.  At  this  point,  some  form  of  the  data  entry  and  editing  facilities  will 
have  been  created  to  support  data  collection.  This  effort  will  be  managed  through  the  means  of  die 
activity  checklist  developed  at  the  start  of  this  phase  of  the  effort. 

Documentation 

Development  of  the  users'  manual  will  take  place  as  the  software  development  process 
nears  completion.  The  manual  will  cover  development  of  system  data,  interfacing  to  another 
LSAR  data  system,  a  screen-by-screen  description  of  data  manipulation  and  analysis  softw  are,  and 
on-line  help  covering  the  same  material.  This  will  be  delivered  w'ith  the  software  and 
programmers’  documentation  at  the  completion  of  the  effort. 

Software  Reporting 

System  documentation  wail  consist  of  the  design  and  implementation  documentation  and 
extensively  annotated  source  code.  It  will  be  delivered,  along  with  the  users'  manual,  as  pan  of 
the  project  final  report.  It  will  be  demonstrated  to  the  government  sponsors  at  the  completion  of 
this  phase  of  the  effort  in  a  formal  review  16  months  after  contract  aw  ard. 


System  F.valuation 

System  evaluation  will  have  two  goals.  The  first  is  a  computational  validation  of  the 
system's  outputs  against  Shaw  AFB  operational,  manning,  and  utilization:  if  the  proposed  system 
generates  the  same  utilization  for  the  same  manning  and  produces  equivalent  manpower  by  AFS  by 
work  center  manning  levels  against  the  same  scenario  as  the  standard  manpower  system,  then  its 
manpower  calculation  will  be  deemed  to  work.  Personnel  requirements  will  be  judged  against  the 
standard  projections  for  these  data  and  their  costs.  Training  course  requirements  will  be  validated 
by  the  ability  of  the  system  to  reconstruct  the  AFSs  training  requirements  from  the  training  to  task 
data.  The  validation  plan  delivered  as  part  of  the  data  collection  documentation  will  provide  an 
output-by-output  validation  criteria  set. 

The  second  goal  will  be  subjective  evaluations  of  the  system  from  potential  user 
communities.  The  government  may  arrange  for  any  number  of  demonstrations  of  the  system 
during  the  four  month  evaluation  period,  including  one  demonstration  to  Pentagon  MPT  managers. 
Prospective  users  will  compare  the  user  facilities  of  the  system  against  the  competing  set  of 
approaches  to  solving  the  same  problem  identified  during  the  data  collection  phase  of  the  effon.  -A 
separate  rating  of  the  perceived  utility  of  the  system  will  also  be  collected,  covering  both  the 
features  that  have  a  comparison  system  (e.g.,  the  manpower  calculation  system)  and  features 
without  a  readily  apparent  comparison  system  (e.g.,  the  early  training/task  association  analysis). 
The  results  of  both  of  these  evaluations  will  be  presented  as  part  of  the  project  final  report. 

The  technical  portion  of  the  effort  will  be  complete  20  months  after  contract  award,  at 
which  time  the  software  and  final  report  draft  will  be  delivered.  A  close-out  meeting  will  also  be 
held  20  months  after  contract  award  at  Wright  Patterson  AFB. 

VI.  FURTHER  DEVELOPMENTS 

The  proposed  development  effort  will  demonstrate  the  soundness  of  the  I’raining/LSA  and 
R&M/MPT  integration  strategy.  Once  this  has  been  established,  UES  will  be  in  an  excellent 
position  to  provide  subcontracting  services  to  larger  firms  in  developing  comparability  data  bases 
and  employing  the  proposed  system  on  large  development  projects.  Depending  upon  the 


successful  marketing  of  the  company  as  an  integrated  logistics  subcontractor,  L’HS  will  continue 
system  development  to  include  a  complete  LSAR  definition  ana  support  additional  trade-of} 
analyses  not  included  in  the  proposed  effon. 

Training  Materia IsAFask  Analysis  Integration 

LSAR  and  ISD  integration  is  one  R&D  area  which  can  build  upon  the  cuirent  effon.  The 
training-to-task  and  training-to-AFS  linkages  from  the  present  effort  identify  the  particular  training 
blocks  associated  with  tasks  and  AFSs,  The  obvious  expansion  would  be  to  manage  the 
behavioral  objectives  for  each  training  block  during  development,  associating  the  behavioral 
objectives  with  training,  blocks,  tasks,  and  AFSs  in  an  expanded  LSAR  data  base.  This  would 
provide  a  more  monolithic  data  integration  between  the  ISD  training  and  LSA  task  management 
responsibilities  thtui  the  proposed  approach  of  dealing  with  training  data  at  the  training-block  level. 
The  outcome  would  be  an  integrated  task  analysis/training  materials  authoring  software  system  ted 
by  the  data  architecture  (with  the  behavioral  objectives  modification)  proposed  as  part  of  this  Phase 
II  effort.  Potential  benefits  include  assistance  in  authoring  both  the  instructional  material  and  the 
task  analysis  data,  automatic  generation  of  training  course  content  changes  as  a  result  of  the 
development  effort,  and  a  closer  monitoring  of  the  training  impacts  of  AFS  restructuring,  closed 
looping,  and  composite  wing  operations. 

Task  Analysis  Product  Integration 

A  further  promising  R&D  area  is  the  integration  of  technical  order  data  generation  w  ith  the 
system  developed  under  the  proposed  Phase  11  effort  and,  if  possible,  the  effort  outlined  in  the 
preceding  paragraph.  This  additional  effort  would  develop  and  integrated  technical  data  and 
instructional  materials  authoring  system  that  is  fed  by  the  system  proposed  in  this  paper.  The 
LSAR  C  Record  task  descriptions  and  associated  training  blocks  (or  behavioral  objectives)  could 
provide  input  to  technical  order  generation  and  course  material  development  for  the  ISA  process. 
Additionally,  scripts  for  some  classes  of  training  simulators  could  be  generated  during  this 
process.  Of  possible  help  in  this  arena  are  developments  form  man-modeling.  The  automatic 
development  of  detailed  task  descriptions,  either  from  heuristic  planning  algorithms  working  upon 
high-level  (i.e.,  LSAR  C  Record)  descriptions  of  ta,sks  or  from  direct  manipulation  of  the  man- 
model  within  a  CAD  system,  could  reduce  the  manpower  required  for  these  activities  by  several 
fold  while  increasing  their  consistency. 

The  benefits  from  this  effort  would  include  the  elimination  of  LSAR  D  Record  task 
analysis.  The  training  and  technical  orders  that  require  this  information  would  be  generated 
directly  from  the  more  fundamental  LSAR  C  Record  and  CAD  data.  HF  and  Safety  analyses 
would  be  performed  on  the  technical  order  data  rather  than  on  the  task  analysis  data,  eliminating 
one  step  in  the  process  for  these  two  di.sciplines.  Inasmuch  as  task  analysis  often  consumes  most 
of  the  logistics  analysis  resources  of  a  large  development  effort,  the  paybacks  for  the  development 
of  this  technology  would  be  enormous. 
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